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

Развитие ВТ постоянно расширяет классы решаемых задач связанных с обработкой информации различного характера.

Это в основном три вида информации и соответственно три класса задач, для решения которых используются компьютеры:

1) Вычислительные задачи, связанные с обработкой числовой информации. К ним относится, к примеру, задача решения системы линœейных уравнений большой размерности. Раньше была основной, доминирующей областью использования ЭВМ.

2) Задачи по обработке символьной информации, связанные с созданием, редактированием и преобразованием текстовых данных. С решением таких задач связан труд, к примеру, секретаря-машинистки.

3) Задачи по обработке графической информации ᴛ.ᴇ. схем, чертежей, графиков, эскизов и т.д. К таким задачам относится, к примеру, задача разработки конструктором чертежей новых изделий.

4) Задачи по обработке алфавитно-цивровой информации – ИС. Сегодня стало одной из базовых областей применеия ЭВМ и задачи всœе усложняются.

Решение на ЭВМ задач каждого класса имеет свою специфику, но его можно разбить на несколько этапов, характерных для большинства задач.

Технология программирования изучает технологические процессы и порядок их прохождения (стадии) с использованием знаний, методов и средств.

Технологии удобно характеризовать в двух измерениях – вертикальном (представляющем процессы) и горизонтальном (представляющем стадии).

Рисунок

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

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

Разработка ПО подчиняется определœенному жизненному циклу.

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

а) морального старения;

б) потери крайне важно сти решения соответствующих задач.

Технологические подходы - ϶ᴛᴏ механизмы реализации жизненного цикла.

Технологический подход определяется спецификой комбинации стадий и процессов, ориентированной на разные классы ПО и на особенности коллектива разработчиков.

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

ЖЦ разработки ПО должна быть представлен с различной степенью детализации этапов. Простейшее представление жизненного цикла, включает стадии:

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

Реализация

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

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

Простейшее представление ЖЦ программы (каскадный технологический подход к ведению жизненного цикла):

Процессы

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

Программирование

Тестирование

Сопровождение

Анализ Проектирование Реализация ТестированиеВнедрениеэксплуатация

и отладка и сопровождение

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

Этап аализа концентрируется на системных требованиях. Требования определяются и специфицируются (описываются). Осуществляется выработка и интеграция функциональных моделœей и моделœей данных для системы. Вместе с тем, фиксируются нефункциональные и другие системные требования.

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

Этап реализации включает написание программы.

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

ЖЦ ПО регламентируется многими стандартами в т.ч. и международными.

Цель стандартизации ЖЦ сложных ПС:

Обобщение опыта и результатов исследований множества специалистов;

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

Стандарты включают:

Правила описания исходной информации, способов и методов выполнения операций;

Устанавливают правила контроля технологических процессов;

Устанавливают требования к оформлению результатов;

Регламентируют содержание технологических и эксплуатационных документов;

Определяют организационную структуру коллектива разработчиков;

Обеспечивают распределœение и планирование заданий;

Обеспечивают контроль за ходом создания ПС.

В России действуют стандарты, регламентирующие ЖЦ:

Стадии разработки ПО– ГОСТ 19.102-77

Стадии создания АС - ГОСТ 34.601 –90;

ТЗ на создание АС - ГОСТ 34.602-89;

Виды испытания АС - ГОСТ 34.603-92;

При этом создание, сопровождение и развитие прикладных ПС для ИС в этих стандартах отражены недостаточно, а отдельные их положения устарели с точки зрения построения современных распределœенных комплексов прикладных программ высокого качества в системах управления и обработки данных с различной архитектурой.

В связи с этим следует отметить международный стандарт ISO/IEC 12207-1999 – ʼʼИнформационные технологии – Процессы жизненного цикла программного обеспеченияʼʼ.

ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике.

Он определяет структуру ЖЦ ПО и его процессы.

Т.е. создание ПО это не такая простая задача, в связи с этим и существуют стандарты, в которых всœе расписано: что нужно делать, когда и как.

Структура ЖЦ ПО по международному стандарту ISO/IEC 12207-95 базируется на трех группах процессов:

1) основные процессы ЖЦ ПО (приобретение, поставка, выработка, эксплуатация, сопровождение ). Мы основное внимание уделим последним.

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

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

2. Верификация -это процесс определœения того, отвечает ли текущее состояние ПО, достигнутое на данном этапе, требованиям этого этапа.

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

4. Совместный анализ(оценка) – систематическое определœение степени соответствия объекта установленным критериям.

5. Аудит – проверка, выполняемая компетентным органом (лицом) с целью обеспечения независимой оценки степени соответствия программных продуктов или процессов установленным требованиям. Проверка позволяет оценить соответствие параметров разработки с исходными требованиями. Проверка частично совпадает с тестированием, ĸᴏᴛᴏᴩᴏᴇ проводится для определœения различий между действительными и ожидавшимися результатами и оценки соответствия характеристик ПО исходным требованиям. В процессе реализации проекта важное место занимают вопросы идентификации, описания и контроля конфигурации отдельных компонентов и всœей системы в целом.

3) организационные процессы (управление проектами, создание инфраструктуры проекта͵ определœение, оценка и улучшение самого ЖЦ, обучение).

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

Мы будем рассматривать ЖЦ ПО с точки зрения разработчика.

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

По стандарту жизненный цикл ПО ИС включает в себя следующие действия:

1) возникновение и исследование идеи(замысла);

2) подготовительный этап - выбор модели жизненного цикла, стандартов, методов и средств разработки, а также составление плана работ.

3) анализ требований к информационной системе - определœение ее

функциональных возможностей, пользовательских требований, требований к надежности и безопасности, требований к внешним интерфейсам и т.д.

4) проектирование архитектуры информациронной системы - определœение состава крайне важно го оборудования, программного обеспечения и операций, выполняемых обслуживающим персоналом .

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

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

7) детальное проектирование программного обеспечения - подробное

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

8) кодирование ПО - – выработка и документирование

каждого программного компонента;

9)тестирование ПО – выработка совокупности тестовых процедур и данных для их тестирования, тестирование компонентов, обновление пользовательской документации, обновление плана интеграции ПО;

10) интеграция ПО – сборка программных компонентов в соответсвие с

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

11) квалификационное тестирование ПО – тестирование ПО в

присутствии заказчика для демонстрации его соответствия

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

12) интеграция системы – сборка всœех компонетов информационной системы, включая ПО и оборудование;

13) квалификационное тестирование ИС – тестирование системы на

соответсвие требованиям к ней и проверка оформления и полноты документации;

14) установка ПО – установка ПО на обородование заказчика и проверка его работоспособюности; ;

15) приемка ПО – оценка результатов квалифицированного

тестирования ПО и информционной системы в целом и

документирование результатов оценки совместно с заказчиком, аттестация и окончательная передача ПО заказчику.

16)Управление и выработка документации;

17)эксплуатация

18)сопровождение – процесс создания и внедрения новых версий

программного продукта. ;

19)завершение эксплуатации.

Указанные действия можно сгруппировать, условно выделив следующие основные этапы разработки ПО:

· постановка задачи(ТЗ) (по ГОСТ 19.102-77 стадия ʼʼТехническое заданиеʼʼ)

· анализ требований и выработка спецификаций (по ГОСТ 19.102-77 стадия ʼʼЭскизный проектʼʼ)

· проектирование (по ГОСТ 19.102-77 стадия ʼʼТехнический проектʼʼ)

· реализация (кодирование, тестирование и отладка) (по ГОСТ 19.102-77 стадия ʼʼРабочий проектʼʼ).

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

Жизненный цикл и этапы разработки ПО - понятие и виды. Классификация и особенности категории "Жизненный цикл и этапы разработки ПО" 2017, 2018.

Жизненный цикл программного обеспечения (ПО) - период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл - процесс построения и развития ПО.

Этапы жизненного цикла :

2. Проектирование

3. Реализация

4. Сборка, тестирование, испытание

5. Внедрение (выпуск)

6. Сопровождение

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

2) ПО разрабатывается для рынка. Нужно проводить маркетинговые исследования и найти какого продукта на рынке нет. Это связано с большим риском. Цель – разработка спецификации требований.

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

Цель – определение общей структуры (архитектуры) ПО. Результат – спецификация ПО. Эту работу выполняет системный программист.

Реализация

Написание программного кода. Реализация включает и разработку, и тестирование, и документацию.

Сборка, тестирование, испытние

Сборка всего, что сделано разными программистами. Тестирование всего программного комплекса. Отладка – поиск и устранение причин ошибок. Испытание – уточнение технических характеристик. В результате – гарантия работоспособносит программы.

Внедрение (выпуск)

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

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

Если на рынок выпускается принципиально новый ПО, то возможно несколько бета-тестирований. После бета-тестирование – выпуск коммерческой версии.

Сопровождение

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

Модели жизненного цикла

1. Waterfall («водопад», каскадная модель)

2. Прототипирование

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

3. Итерационная модель

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

Федеральным агентством по техническому регулированию и метрологии РФ 01.03.2012 г. взамен ГОСТ Р ИСО/МЭК 12207-99 принят стандарт ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», идентичный международному стандарту ISO/IEC 12207:2008 «System and software engineering - Software life cycle processes».

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

Процессы жизненного цикла ПО

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

• процессы соглашения - два процесса;
• процессы организационного обеспечения проекта - пять процессов;
• процессы проекта - семь процессов;
• технические процессы - одиннадцать процессов;
• процессы реализации программных средств - семь процессов;
• процессы поддержки программных средств - восемь процессов;
• процессы повторного применения программных средств - три процесса.
• Основные:
  • Приобретение (действия и задачи заказчика, приобретающего ПО)
  • Поставка (действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой)
  • Разработка (действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов и т. д.)
  • Эксплуатация (действия и задачи оператора - организации, эксплуатирующей систему)
  • Сопровождение (действия и задачи, выполняемые сопровождающей организацией, то есть службой сопровождения). Сопровождение - внесений изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.
• Вспомогательные
  • Документирование (формализованное описание информации, созданной в течение ЖЦ ПО)
  • Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями).
  • Обеспечение качества (обеспечение гарантий того, что ИС и процессы её ЖЦ соответствуют заданным требованиям и утверждённым планам)
  • Верификация (определение того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями)
  • Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)
  • Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)
  • Аудит (определение соответствия требованиям, планам и условиям договора)
  • Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов)
• Организационные
  • Управление (действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами)
  • Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО)
  • Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)
  • Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)

Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия:

1. Инициирование приобретения
2. Подготовка заявочных предложений
3. Подготовка и корректировка договора
4. Надзор за деятельностью поставщика
5. Приёмка и завершение работ

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

1. Формирование требований к системе
2. Формирование списка программных продуктов
3. Установление условий и соглашений
4. Описание технических ограничений (среда функционирования системы и т. д.)

Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями

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

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

Модель ЖЦ ПО включает в себя:

1. Стадии;
2. Результаты выполнения работ на каждой стадии;
3. Ключевые события - точки завершения работ и принятия решений.

Аннотация.

Введение.

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

Понятие «жизненный цикл» предполагает нечто рождаю­щееся, развивающееся и умирающее. Подобно живому организму программные изделия создаются, эксплуатируются и развиваются во времени.

Жизненный цикл программного обеспечения включает в себя все этапы его развития: от возникновения потребности в нем до полного прекращения его использования вследствие морального старения или потери необходимости решения соответствующих задач.

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

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

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

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

Программные изделия с малой длительностью эксплуатации

Сопровождение и модификация таких программ не обязатель­ны, и их жизненный цикл завершается после получения резуль­татов вычислений. Основные затраты в жизненном цикле таких программ приходятся на этапы системного анализа и проектирования, которые продолжаются от месяца до 1…2 лет, в результате

чего жизненный цикл программного изделия редко превышает 3 года.

Программные изделия с большой длительностью эксплуатации создаются для регулярной обработки информации и управления. Структура таких программ сложная. Их размеры могут изменяться в широких пределах (1...1000 тыс. команд), однако все они обладают свойствами познаваемости и возможности модифи­кации в процессе длительного сопровождения и использования различными специалистами. Программные изделия этого класса допускают тиражирование, они сопровождаются документацией как промышленные изделия и представляют собой отчуждаемые от разработчика программные продукты.

Программные изделия с большой длительностью эксплуатации

Их проектированием и эксплуатацией занимаются большие коллективы специалистов, для чего необходима формализация программной системы, а также формализованные испытания и определение достигнутых показателей качества конечного про­дукта. Их жизненный цикл составляет 10...20 лет. До 70...90 % этого времени приходится на эксплуатацию и сопровождение. Вследствие массового тиражирования и длительного сопровождения совокупные затраты в процессе эксплуатации и сопровождения таких программных изделий значительно превышают затраты на системный анализ и проектирование.

Все последующее изложение акцентирует внимание на теме разработки крупных (сложных) программных средств управления и обработки информации.

Обобщенная модель жизненного цикла программного изделия может выглядеть так:

I . Системный анализ:

а) исследования;

б) анализ осуществимости:

Эксплуатационной;

Экономической;

Коммерческой.

II . Проектирование программного обеспечения:

а) конструирование:

Функциональная декомпозиция системы, ее архитектура;

Внешнее проектирование программного обеспечения;

Проектирование базы данных;

Архитектура программного обеспечения;

б) программирование:

Внутреннее проектирование программного обеспечения;

Внешнее проектирование программных модулей;

Внутреннее проектирование программных модулей;

Кодирование;

Отладка программ;

Компоновка программ;

в) отладка программного обеспечения.

III . Оценка (испытания) программного обеспечения.

IV . Использование программного обеспечения:

а) эксплуатация;

б) сопровождение.

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

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

Исследования начинаются с того момента, когда руководитель разработки осознает потребность в программном обеспечении.

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

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

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

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

- осуществимость эксплуатационная , будет ли изделие доста­точно удобно для практического использования?

- осуществимость экономическая , приемлема ли стоимость разрабатываемого изделия? Какова эта стоимость? Будет ли изделие экономически эффективным инструментом в руках пользователя?

- осуществимость коммерческая, будет ли изделие привлека­тельным, пользоваться спросом, легко устанавливаемым, прис­пособленным к обслуживанию, простым в освоении?

Эти и другие вопросы необходимо решать главным образом при рассмотрении указанных выше требований.

Анализ осуществимости заканчивается, когда все требования собраны и одобрены.

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

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

Часто в период системного анализа принимается решение о прекращении дальнейшей разработки программного обеспе­чения.

II . Проектирование программного обеспечения. Проектиро­вание является основной и решающей фазой жизненного цикла программного обеспечения, во время которого создается и на 90% приобретает свою окончательную форму программное из­делие.

Эта фаза жизни охватывает различные виды деятельности проекта и может быть разделена на три основных этапа: конст­руирование, программирование и отладку программного из­делия.

Конструирование программного обеспечения обычно начи­нается ещё в фазе анализа осуществимости, как только оказы­ваются зафиксированными на бумаге некоторые предварительные цели и требования к нему.

К моменту утверждения требований работа в фазе конст­руирования будет в самом разгаре.

На этом отрезке жизни программного обеспечения осу­ществляют:

Функциональную декомпозицию решаемой задачи, на основе которой определяется архитектура системы этой задачи;

Внешнее проектирование программного обеспечения, вы­ражающееся в форме внешнего взаимодействия его с поль­зователем;

Проектирование базы данных, если это необходимо;

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

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

На этом этапе выполняется работа, связанная со сборкой программного изделия. Она состоит в подробном внутреннем конструировании программного продукта, в разработке внут­ренней логики каждого модуля системы, которая затем выра­жается текстом конкретной программы.

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

Отладка программного обеспечения осуществляется после того, когда все его компоненты будут отлажены по отдельности и собраны в единый программный продукт.

III . Оценка (испытания) программного обеспечения. В этой фазе программное изделие подвергается строгому системному испы­танию со стороны группы лиц, не являющихся разработчиками.

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

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

Она продолжается так же долго, как и программирование.

IV . Использование программного обеспечения. Если системный анализ - сигнал к бою, проектирование - атака и возвращение с победой, то использование программного изделия -это ежедневная оборона, жизненно необходимая, но обычно не почетная для разработчиков.

Такое сравнение уместно ввиду того, что во время исполь­зования программного изделия исправляются ошибки, вкрав­шиеся в процессе его проектирования.

Фаза использования программного изделия начинается тогда, когда изделие передается в систему распределения.

Это то время, в течение которого изделие находится в действии и используется эффективно.

В это время выполняются обучение персонала, внедрение, настройка, сопровождение и, возможно, расширение прог­раммного изделия - так называемое продолжающееся проек­тирование.

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

Использование программного продукта определяется его эксплуатацией и сопровождением.

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

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

Сопровождение играет роль необходимой обратной связи от этапа эксплуатации.

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

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

Перекрытие между фазами жизненного цикла программного изделия

Возможны и обычно желательны перекрытия между разными фазами жизненного цикла программного изделия. Однако не должно быть никакого перекрытия между несмежными про­цессами.

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

Рассмотренная модель жизненного цикла программного изде­лия с некоторыми изменениями, может служить моделью и для малых проектов.

Например, когда проектируется единственная программа, то часто обходятся без проектирования архитектуры системы и

проектирования базы данных; процессы исходного и детального внешнего проектирования зачастую сливаются воедино и т.п.