Жизненный цикл программного обеспечения
Одним из базовых понятий методологии проектирования ПО является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт 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-го поколения;
· Внедрение. Разработчики обучают пользователей работе в среде новой ПО.
Жизненный цикл программного обеспечения
Жизненный цикл программного обеспечения - период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. (Стандарт IEEE Std 610.12)
Необходимость определения этапов жизненного цикла (ЖЦ) ПО обусловлена стремлением разработчиков к повышению качества ПО за счет оптимального управления разработкой и использования разнообразных механизмов контроля качества на каждом этапе, начиная от постановки задачи и заканчивая авторским сопровождением ПО. Наиболее общим представлением жизненного цикла ПО является модель в виде базовых этапов - процессов, к которым относятся:
Системный анализ и обоснование требований к ПО;
Предварительное (эскизное) и детальное (техническое) проектирование ПО;
Разработка программных компонент, их комплексирование и отладка ПО в целом;
Испытания, опытная эксплуатация и тиражирование ПО;
Регулярная эксплуатация ПО, поддержка эксплуатации и анализ результатов;
Сопровождение ПО, его модификация и совершенствование, создание новых версий.
Данная модель является общепринятой и соответствует как отечественным нормативным документам в области разработки программного обеспечения, так и зарубежным. С точки зрения обеспечения технологической безопасности целесообразно рассмотреть более подробно особенности представления этапов ЖЦ в зарубежных моделях, так как именно зарубежные программные средства являются наиболее вероятным носителем программных дефектов диверсионного типа.
Стандарты жизненного цикла ПО
ГОСТ 34.601-90
ISO/IEC 12207:1995 (российский аналог - ГОСТ Р ИСО/МЭК 12207-99)
Графическое представление моделей ЖЦ позволяет наглядно выделить их особенности и некоторые свойства процессов.
Первоначально была создана каскадная модель ЖЦ, в которой крупные этапы начинались друг за другом с использованием результатов предыдущих работ. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. Основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем.
Наиболее специфической является спиралевидная модель ЖЦ. В этой модели внимание концентрируется на итерационном процессе начальных этапов проектирования. На этих этапах последовательно создаются концепции, спецификации требований, предварительный и детальный проект. На каждом витке уточняется содержание работ и концентрируется облик создаваемого ПО, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации оцениваются:
Риск превышения сроков и стоимости проекта;
Необходимость выполнения ещё одной итерации;
Степень полноты и точности понимания требований к системе;
Целесообразность прекращения проекта.
Стандартизация ЖЦ ПО проводится по трем направлениям. Первое направление организуется и стимулируется Международной организацией по стандартизации (ISO - International Standard Organization) и Международной комиссией по электротехнике (IEC - International Electro-technical Commission). На этом уровне осуществляется стандартизация наиболее общих технологических процессов, имеющих значение для международной кооперации. Второе направление активно развивается в США Институтом инженеров электротехники и радиоэлектроники (IEEE - Institute of Electrotechnical and Electronics Engineers) совместно с Американским национальным институтом стандартизации (American Na-tional Standards Institute-ANSI). Стандарты ISO/IEC и ANSI/IEEE в основном имеют рекомендательный характер. Третье направление стимулируется Министерством обороны США (Department of Defense-DOD). Стандарты DOD имеют обязательный характер для фирм, работающих по заказу Министерства обороны США.
Для проектирования ПО сложной системы, особенно системы реального времени, целесообразно использовать общесистемную модель ЖЦ, основанную на объединении всех известных работ в рамках рассмотренных базовых процессов. Эта модель предназначена для использования при планировании, составлении рабочих графиков, управлении различными программными проектами.
Совокупность этапов данной модели ЖЦ целесообразно делить на две части, существенно различающихся особенностями процессов, технико-экономическими характеристиками и влияющими на них факторами.
В первой части ЖЦ производится системный анализ, проектирование, разработка, тестирование и испытания ПО. Номенклатура работ, их трудоемкость, длительность и другие характеристики на этих этапах существенно зависят от объекта и среды разработки. Изучение подобных зависимостей для различных классов ПО позволяет прогнозировать состав и основные характеристики графиков работ для новых версий ПО.
Вторая часть ЖЦ, отражающая поддержку эксплуатации и сопровождения ПО, относительно слабо связана с характеристиками объекта и среды разработки. Номенклатура работ на этих этапах более стабильна, а их трудоемкость и длительность могут существенно изменяться, и зависят от массовости применения ПО. Для любой модели ЖЦ обеспечение высокого качества программных комплексов возможно лишь при использовании регламентированного технологического процесса на каждом из этих этапов. Такой процесс поддерживается средствами автоматизации разработки, которые целесообразно выбирать из имеющихся или создавать с учетом объекта разработки и адекватного ему перечня работ.
Тема: Классические и гибкие модели ЖЦПП: определение, описание, отличительные особенности, последовательность этапов. Методы выбора модели ЖЦПП при разработке ПО различных предметных областей.
Источник информации https://www.intuit.ru/studies/courses/3632/874/print_lecture/14297
Модели и стадии ЖЦ ПО
Под моделью ЖЦ ПО понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении ЖЦ ПО . Модель ЖЦ зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.
Стандарт ISO / IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО . Его положения являются общими для любых моделей ЖЦ, методов и технологий разработки ПО . Стандарт описывает структуру процессов ЖЦ ПО , но не конкретизирует, как реализовать или выполнить действия и задачи, включенные в эти процессы.
Модель ЖЦ любого конкретного ПО определяет характер процесса его создания, который представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии (фазы) работ , выполнение которых необходимо и достаточно для создания ПО , соответствующего заданным требованиям.
Под стадией (фазой) создания ПО понимается часть процесса создания ПО , ограниченная некоторыми временными рамками и заканчивающаяся выпуском конкретного продукта (моделей ПО , программных компонентов, документации и пр.), определяемого заданными для данной стадии требованиями. Стадии создания ПО выделяются по соображениям рационального планирования и организации работ , заканчивающихся заданными результатами. В состав ЖЦ ПО обычно включаются следующие стадии:
- формирование требований к ПО;
- проектирование (разработка системного проекта);
- реализация (может быть разбита на подэтапы: детальное проектирование, кодирование);
- тестирование (может быть разбито на автономное и комплексное тестирование и интеграцию);
- ввод в действие (внедрение);
- эксплуатация и сопровождение;
- снятие с эксплуатации.
Некоторые специалисты вводят дополнительно начальную стадию – анализ осуществимости системы. Здесь имеется в виду программно-аппаратная система, для которой создается, приобретается или модифицируется ПО .
Стадия формирования требований к ПО является одной из важнейших и определяет в значительной (даже решающей!) степени успех всего проекта. Началом этой стадии является получение одобренной и утвержденной архитектуры системы с включением основных соглашений о распределении функций между аппаратурой и программами. Этот документ должен также содержать подтверждение общего представления о функционировании ПО с включением основных соглашений о распределении функций между человеком и системой.
Стадия формирования требований к ПО включает следующие этапы.
- Планирование работ, предваряющее работы над проектом. Основными задачами этапа являются определение целей разработки, предварительная экономическая оценка проекта, построение плана-графика выполнения работ, создание и обучение совместной рабочей группы.
- Проведение обследования деятельности автоматизируемой организации (объекта), в рамках которого осуществляются предварительное выявление требований к будущей системе определение структуры организации, определение перечня целевых функций организации, анализ распределения функций по подразделениям и сотрудникам, выявление функциональных взаимодействий между подразделениями, информационных потоков внутри подразделений и между ними, внешних по отношению к организации объектов и внешних информационных воздействий, анализ существующих средств автоматизации деятельности организации.
- модели "AS-IS" ("как есть"), отражающей существующее на момент обследования положение дел в организации и позволяющей понять, каким образом работает данная организация, а также выявить узкие места и сформулировать предложения по улучшению ситуации;
- модели "TO-BE" ("как должно быть"), отражающей представление о новых технологиях работы организации.
Построение модели деятельности организации (объекта), предусматривающее обработку материалов обследования и построение двух видов моделей:
Каждая из моделей должна включать полную функциональную и информационную модель деятельности организации, а также (при необходимости) модель, описывающую динамику поведения организации. Заметим, что построенные модели имеют самостоятельное практическое значение , независимо от того, будет ли на предприятии разрабатываться и внедряться информационная система, поскольку с их помощью можно обучать сотрудников и совершенствовать бизнес-процессы предприятия.
Результатом завершения стадии формирования требований к ПО являются спецификации ПО , функциональные, технические и интерфейсные спецификации, для которых подтверждена их полнота , проверяемость и осуществимость.
Стадия проектирования включает следующие этапы.
Разработка системного проекта ПО. На этом этапе дается ответ на вопрос "Что должна делать будущая система?", а именно: определяются архитектура системы, ее функции, внешние условия функционирования, интерфейсы и распределение функций между пользователями и системой, требования к программным и информационным компонентам, состав исполнителей и сроки разработки, план отладки ПО и контроль качества.
Основу системного проекта составляют модели проектируемой системы, которые строятся на модели "TO-BE". Результатом разработки системного проекта должна быть одобренная и подтвержденная спецификация требований к ПО: функциональные, технические и интерфейсные спецификации, для которых подтверждена их полнота, проверяемость и осуществимость.
- Разработка детального (технического) проекта. На этом этапе осуществляется собственно проектирование ПО, включающее проектирование архитектуры системы и детальное проектирование. Таким образом, дается ответ на вопрос: "Как построить систему, чтобы она удовлетворяла требованиям?"
Результатом детального проектирования является разработка верифицированной спецификации ПО , включающей:
- формирование иерархии программных компонентов, межмодульных интерфейсов по данным и управлению;
- спецификация каждого компонента ПО, имени, назначения, предположений, размеров, последовательности вызовов, входных и выходных данных, ошибочных выходов, алгоритмов и логических схем;
- формирование физической и логической структур данных до уровня отдельных полей;
- разработку плана распределения вычислительных ресурсов (времени центральных процессоров, памяти и др.);
- верификацию полноты, непротиворечивости, осуществимости и обоснованности требований;
- предварительный план комплексирования и отладки, план руководства для пользователей и приемных испытаний.
Завершением стадии детального проектирования является сквозной контроль проекта или критический поблочный анализ проекта.
Стадия реализации – выполнение следующих работ .
Разработка верифицированной детальной спецификации каждой подпрограммы (блока не более чем из 100 исходных команд языка высокого уровня).
Внешние спецификации должны содержать следующие сведения:
- имя модуля - указывается имя, применяемое для вызова модуля (для модуля с несколькими входами для каждого входа должны быть отдельные спецификации);
- функция – дается определение функции или функций, выполняемых модулем;
- список параметров (число и порядок следования), передаваемых модулю;
- входные параметры – точное описание всех данных, возвращаемых модулем (должно быть определено поведение модуля при любых входных условиях);
- внешние эффекты (печать сообщения, чтение запроса с терминала и т. п.).
- Проектирование логики модулей и программирование (кодирование) модулей.
- Проверка правильности модулей.
- Тестирование модулей.
- Описание базы данных до уровня отдельных параметров, символов и битов.
- План приемных испытаний.
- Руководство пользователю.
- Предварительный план комплексирования и отладки. Содержание последующих стадий в основном совпадает с соответствующими процессами ЖЦ ПО. Вообще технологические стадии выделяются исходя из соображений разумного и рационального планирования и организации работ. Возможный вариант взаимосвязи и стадий работ с процессами ЖЦ ПО показан на рисунке.
Рис. 1.
Виды моделей ЖЦ ПО
Каскадная модель (классический жизненный цикл)
Эта модель обязана своим появлением У. Ройсу (1970 г.). Модель имеет и другое название – водопад (waterfall). Особенность модели – переход на следующую ступень осуществляется только после того, как будет полностью завершена работа на предыдущей стадии; возвратов на пройденные стадии не предусматривается.
Рис. 2.
Требования к разрабатываемой ПС, определенные на стадиях формирования и анализа, строго документируются в виде ТЗ и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации (ТЗ, ЭП, ТП, РП), достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Критерием качества разработки при таком подходе является точность выполнения спецификаций ТЗ. Основное внимание разработчиков сосредоточивается на достижении оптимальных значений технических характеристик разрабатываемой ПС – производительности, объема занимаемой памяти и др.
Преимущества каскадной модели :
- на каждой стадии формируется законченный набор проектной документации, отвечающей критериям полноты и согласованности;
- выполняемые в логической последовательности стадии работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении ПС, для которых в самом начале проекта можно полно и четко сформулировать все требования. Пока все это контролируется стандартами и различными комиссиями госприемки, схема работает хорошо.
Недостатки каскадной модели :
- выявление и устранение ошибок производится только на стадии тестирования, которое может существенно растянуться;
- реальные проекты часто требуют отклонения от стандартной последовательности шагов;
- цикл основан на точной формулировке исходных требований к ПС, реально в начале проекта требования заказчика определены лишь частично;
- результаты работ доступны заказчику только по завершении проекта.
Итерационная модель ЖЦ ПС
С ростом коммерческих проектов выяснилось, что не всегда удается детально проработать проект будущей системы, поскольку многие аспекты ее функционирования в динамических сферах деятельности (бизнес) меняются, пока система создается. Потребовалось изменить процесс разработки так, чтобы гарантировать внесение необходимых исправлений после завершения какого-либо этапа разработки. Так появилась итерационная модель ЖЦ ПС, называемая моделью с промежуточным контролем или моделью с циклическим повторением фаз.
Рис. 3.
В итерационной модели недостатки проектирования и программирования могут быть устранены позже путем частичного возврата на предыдущую стадию. Чем ниже уровень обнаружения ошибки, тем дороже ее исправление. Если стоимость усилий, необходимых для обнаружения и устранения ошибок на стадии написания кода, принять за единицу, то стоимость выявления и устранения ошибки на стадии выработки требований будет в 5-10 раз меньше, а стоимость выявления и устранения ошибки на стадии сопровождения – в 20 раз больше.
Рис. 4.
В такой ситуации огромное значение приобретает этап формулирования требований, составление спецификаций и создание плана системы. Программные архитекторы несут личную ответственность за все последующие изменения проектных решений. Объем документации исчисляется тысячами страниц, число утверждающих заседаний огромно. Многие проекты так никогда и не покидают этап планирования, впав в " паралич анализа". Одним из возможных путей исключения подобных ситуаций является макетирование (прототипирование).
Макетирование
Часто заказчик не может сформулировать требования по вводу, обработке или выводу данных для будущего программного продукта. Разработчик может сомневаться в приспособленности продукта к операционной системе, в форме диалога с пользователем или эффективности алгоритма. В таких случаях целесообразно использовать макетирование. Основная цель макетирования – снять неопределенность в требованиях заказчика. Макетирование (прототипирование) – процесс создания модели требуемого продукта.
Модель может принимать следующие формы.
- Бумажный макет (рисованная схема человеко-машинного диалога) или макет на основе ПК.
- Работающий макет, реализующий некоторую часть требуемых функций.
- Существующая программа, характеристики которой должны быть улучшены.
Как показано на рисунке, макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик.
Рис. 5.
Последовательность действий при макетировании представлена на рисунке. Макетирование начинается со сбора и уточнения требований к создаваемой программной системе. Разработчик и заказчик совместно определяют цели ПО, устанавливают, какие требования известны, а какие предстоит доопределить. Затем выполняется быстрое проектирование. В нем сосредотачиваются на характеристиках, которые должны быть видимыми пользователю. Быстрое проектирование приводит к построению макета. Макет оценивается заказчиком и используется для уточнения требований к ПО. Итерации продолжаются до тех пор, пока макет не выявит все требования заказчика и даст возможность разработчику понять, что должно быть сделано.
Достоинства макетирования – возможность обеспечения определения полных требований к системе. Недостатки макетирования:
- заказчик может принять макет за продукт;
- разработчик может принять макет за продукт.
Следует пояснить суть недостатков. Когда заказчик видит работающую версию ПС, он перестает сознавать, что в погоне за работающим вариантом ПС оставлены нерешенными многие вопросы качества и удобства сопровождения системы. Когда же заказчику об этом говорит разработчик, то ответом может быть возмущение и требование скорейшего превращения макета в рабочий продукт. Это отрицательно сказывается на управлении разработкой ПО.
Рис. 6.
С другой стороны, для быстрого получения работающего макета разработчик часто идет на определенные компромиссы. Например, могут использоваться не самые подходящие языки программирования или операционная система. Для простой демонстрации может применяться неэффективный (простой) алгоритм. Спустя некоторое время разработчик забывает о причинах, по которым эти средства не подходят. В результате далеко не идеальный выбранный вариант интегрируется в систему.
Прежде чем рассматривать другие модели ЖЦ ПО, которые пришли на смену каскадной модели , следует остановиться на стратегиях конструирования программных систем. Именно стратегия конструирования ПО во многом определяет модель ЖЦ ПО.
Стратегии конструирования ПО
Существует три стратегии конструирования программных систем:
- однократный проход (каскадная стратегия, рассмотренная выше) – линейная последовательность этапов конструирования;
- инкрементная стратегия. В начале процесса определяются все пользовательские и системные требования, оставшаяся часть конструирования выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система;
- эволюционная стратегия. Система также строится в виде последовательности версий, но в начале процесса определяются не все требования. Требования уточняются в результате разработки версий. Характеристики стратегий конструирования ПО с соответствии с требованиями стандарта IEEE/EIA 12207 приведены в таблице 1.
Инкрементная модель
Инкрементная модель является классическим примером инкрементной стратегии конструирования. Она объединяет элементы последовательной водопадной модели с итерационной философией макетирования (предложена Б. Боэмом как усовершенствование каскадной модели ). Каждая линейная последовательность здесь вырабатывает поставляемый инкремент ПО. Например, ПО для обработки слов в 1-м инкременте (версии) реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте – более сложные возможности редактирования и документирования; в 3-м инкременте – проверку орфографии и грамматики; в 4-м инкременте – возможности компоновки страницы.
Первый инкремент приводит к получению базового продукта, реализующего базовые требования (правда, многие вспомогательные требования остаются нереализованными). План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики и функциональность.
По своей природе инкрементный процесс итеративен, но, в отличие от макетирования, инкрементная модель обеспечивает на каждом инкременте работающий продукт.
Схема такой модели ЖЦ ПО приведена на рисунке. Одной из современных реализаций инкрементного подхода является экстремальное программирование (ориентировано на очень малые приращения функциональности).
Рис. 7.
Спиральная модель ЖЦ ПО
Спиральная модель – классический пример применения эволюционной стратегии конструирования. Модель (автор Б. Боэм, 1988) базируется на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент – анализ риска, отсутствующий в этих парадигмах. Модель определяет четыре действия, представляемые четырьмя квадрантами спирали.
Рис. 8.
- Планирование – определение целей, вариантов и ограничений.
- Анализ риска – анализ вариантов и распознавание/выбор риска.
- Конструирование – разработка продукта следующего уровня.
- Оценивание – оценка заказчиком текущих результатов конструирования.
Интегрирующий аспект спиральной модели очевиден при учете радиального измерения спирали. С каждой итерацией по спирали строятся все более полные версии ПС. В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование, используемое в квадранте конструирования.
Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации (квадрант оценки заказчиком). Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде "продолжать, не продолжать". Если риск слишком велик, проект может быть остановлен.
В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей модели системы. В каждом цикле по спирали требуется конструирование (нижний правый квадрант), которое может быть реализовано классическим жизненным циклом или макетированием. Заметим, что количество действий по разработке (происходящих в правом нижнем квадранте) возрастает по мере продвижения от центра спирали.
Эти действия пронумерованы и имеют следующее содержание:
- – начальный сбор требований и планирование проекта;
- – та же работа, но на основе рекомендаций заказчика;
- – анализ риска на основе начальных требований;
- – анализ риска на основе реакции заказчика;
- – переход к комплексной системе;
- – начальный макет системы;
- – следующий уровень макета;
- – сконструированная система;
- – оценивание заказчиком.
Достоинства спиральной модели :
- наиболее реально (в виде эволюции) отображает разработку программного обеспечения;
- позволяет явно учитывать риск на каждом витке эволюции разработки;
- включает шаг системного подхода в итерационную структуру разработки;
- использует моделирование для уменьшения риска и совершенствования программного изделия.
Недостатки спиральной модели :
- сравнительная новизна (отсутствует достаточная статистика эффективности модели);
- повышенные требования к заказчику;
- трудности контроля и управления временем разработки.
Модель спирального процесса разработки является наиболее распространенной в настоящее время. Самыми известными ее вариантами являются RUP (Rational Unified Process) от фирмы Rational и MSF (Microsoft Solution Framework). В качестве языка моделирования используется язык UML (Unified Modeling Language). Создание системы предполагается проводить итерационно, двигаясь по спирали и, проходя через одни и те же стадии, на каждом витке уточнять характеристики будущего продукта. Казалось бы, теперь все хорошо: и планируется только то, что можно предвидеть, разрабатывается то, что запланировано, и пользователи начинают знакомиться с продуктом заранее, имея возможность внести необходимые коррективы.
Однако для этого нужны очень большие средства. Действительно, если раньше можно было создавать и распускать группы специалистов по мере необходимости, то теперь все они должны постоянно участвовать в проекте: архитекторы, программисты, тестировщики, инструкторы и т. д. Более того, усилия различных групп должны быть синхронизированы, чтобы своевременно отражать проектные решения и вносить необходимые изменения.
Рациональный унифицированный процесс
Рациональный унифицированный процесс (Rational Unified Process, RUP) – одна из лучших методологий разработки программного обеспечения. Основываясь на опыте многих успешных программных проектов, RUP позволяет создавать сложные программные системы, основываясь на индустриальных методах разработки. Предпосылки для разработки RUP зародились в начале 1980-х гг. в Rational Software corporation. В начале 2003 г. Rational приобрела IBM. Одним из основных столпов, на которые опирается RUP, является процесс создания моделей при помощи унифицированного языка моделирования (UML).
RUP – одна из спиральных методологий разработки программного обеспечения. Методология поддерживается и развивается компанией Rational Software. В качестве языка моделирования в общей базе знаний используется язык Unified Modelling Language (UML). Итерационная и инкрементная разработка программного обеспечения в RUP предполагает разделение проекта на несколько проектов, которые выполняются последовательно, и каждая итерация разработки четко определена набором целей, которые должны быть достигнуты в конце итерации. Конечная итерация предполагает, что набор целей итерации должен в точности совпадать с набором целей, указанных заказчиком продукта, то есть все требования должны быть выполнены.
Процесс предполагает эволюционирование моделей; итерация цикла разработки однозначно соответствует определенной версии модели программного обеспечения. Каждая из итераций содержит элементы управления жизненным циклом программного обеспечения : анализ и дизайн (моделирование), реализация, интегрирование, тестирование, внедрение. В этом смысле RUP является реализацией спиральной модели , хотя довольно часто изображается в виде графика-таблицы..
На данном рисунке представлены два измерения: горизонтальная ось представляет время и показывает временные аспекты жизненного цикла процесса; вертикальная ось представляет дисциплины, которые определяют физическую структуру процесса. Видно, как с течением времени изменяются акценты в проекте. Например, в ранних итерациях больше времени отводится требованиям; в поздних итерациях больше времени отводится реализации. Горизонтальная ось сформирована из временных отрезков – итераций, каждая из которых является самостоятельным циклом разработки; цель цикла – принести в конечной продукт некоторую заранее определенную осязаемую доработку, полезную с точки зрения заинтересованных лиц.
Рис. 9.
По оси времени жизненный цикл делится на четыре основные фазы.
- Начало (Inception) – формирование концепции проекта, понимание того, что мы создаем, представление о продукте (vision), разработка бизнес-плана (business case), подготовка прототипа программы или частичного решения. Это фаза сбора информации и анализа требований, определение образа проекта в целом. Цель – получить поддержку и финансирование. В конечной итерации результат этого этапа – техническое задание.
- Проектирование, разработка (Elaboration) – уточнение плана, понимание того, как мы это создаем, проектирование, планирование необходимых действий и ресурсов, детализация особенностей. Завершается этап исполняемой архитектурой, когда все архитектурные решения приняты и риски учтены. Исполняемая архитектура представляет собой работающее программное обеспечение, которое демонстрирует реализацию основных архитектурных решений. В конечной итерации это – технический проект.
- Реализация, создание системы (Construction) – этап расширения функциональности системы, заложенной в архитектуре. В конечной итерации это – рабочий проект.
- Внедрение, развертывание (Transition). Создание конечной версии продукта. Фаза внедрения продукта, поставка продукта конкретному пользователю (тиражирование, доставка и обучение).
Вертикальная ось состоит из дисциплин, каждая из них может быть более детально расписана с точки зрения выполняемых задач, ответственных за них ролей, продуктов, которые подаются задачам на вход и выпускаются в ходе их выполнения и т.д.
По этой оси располагаются ключевые дисциплины жизненного цикла RUP, которые часто на русском языке называют процессами, хотя это не совсем верно с точки зрения данной методологии, поддерживаемые инструментальными средствами IBM (и/или третьих фирм).
- Бизнес-анализ и моделирование ( Business modeling ) обеспечивает реализацию принципов моделирования с целью изучения бизнеса организации и накопления знаний о нем, оптимизации бизнес-процессов и принятия решения об их частичной или полной автоматизации.
- Управление требованиями (Requirements) посвящено получению информации от заинтересованных лиц и ее преобразованию в набор требований, определяющих содержание разрабатываемой системы и подробно описывающих ожидания от того, что система должна делать.
- Анализ и проектирование (Analysis and design) охватывает процедуры преобразования требований в промежуточные описания (модели), представляющие, как эти требования должны быть реализованы.
- Реализация (Implementation) охватывает разработку кода, тестирование на уровне разработчиков и интеграцию компонентов, подсистем и всей системы в соответствии с установленными спецификациями.
- Тестирование (Test) посвящено оценке качества создаваемого продукта.
- Развертывание (Deployment) охватывает операции, имеющие место при передаче продуктов заказчикам и обеспечении доступности продукта конечным пользователям.
- Конфигурационное управление и управление изменениями (Configuration management) посвящено синхронизации промежуточных и конечных продуктов и управлению их развитием в ходе проекта и поиском скрытых проблем.
- Управление проектом (Management) посвящено планированию проекта, управлению рисками, контролю хода его выполнения и непрерывной оценке ключевых показателей.
- Управление средой (Environment) включает элементы формирования среды разработки информационной системы и поддержки проектной деятельности.
В зависимости от специфики проекта могут быть использованы любые средства IBM Rational, а также третьих фирм. В RUP рекомендовано следовать шести практикам, позволяющим успешно разрабатывать проект: итеративная разработка; управление требованиями; использование модульных архитектур; визуальное моделирование; проверка качества; отслеживание изменений.
Неотъемлемую часть RUP составляют артефакты (artefact), прецеденты ( precedent ) и роли (role). Артефакты – это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом. Прецеденты – это последовательности действий, выполняемых системой для получения наблюдаемого результата. Фактически любой результат работы индивидуума или группы является артефактом, будь то документ анализа, элемент модели, файл кода, тестовый скрипт, описание ошибки и т. п. За создание того или иного вида артефактов отвечают определенные специалисты. Таким образом, RUP четко определяет обязанности – роли – каждого члена группы разработки на том или ином этапе, то есть когда и кто должен создать тот или иной артефакт. Весь процесс разработки программной системы рассматривается в RUP как процесс создания артефактов – начиная с первоначальных документов анализа и заканчивая исполняемыми модулями, руководствами пользователя и т.п.
Для компьютерной поддержки процессов RUP в IBM разработан широкий набор инструментальных средств:
- Rational Rose – CASE- средство визуального моделирования информационных систем, имеющее возможности генерирования элементов кода. Специальная редакция продукта – Rational Rose RealTime – позволяет на выходе получить исполняемый модуль;
- Rational Requisite Pro – средство управления требованиями, которое позволяет создавать, структурировать, устанавливать приоритеты, отслеживать, контролировать изменения требований, возникающие на любом этапе разработки компонентов приложения;
- Rational ClearQuest – продукт для управления изменениями и отслеживания дефектов в проекте (bug tracking), тесно интегрирующийся со средствами тестирования и управления требованиями и представляющий собой единую среду для связывания всех ошибок и документов между собой;
- Rational SoDA – продукт для автоматического генерирования проектной документации, позволяющий установить корпоративный стандарт на внутрифирменные документы. Возможно также приведение документации к уже существующим стандартам (ISO, CMM);
- Rational Purify, Rational Quantify Rational PureCoverage, – средства тестирования и отладки;
- Rational Visual Quantify – средство измерения характеристик для разработчиков приложений и компонентов, программирующих на C/C++, Visual Basic и Java; помогает определять и устранять узкие места в производительности ПО;
- Rational Visual PureCoverage – автоматически определяет области кода, которые не подвергаются тестированию;
- Rational ClearCase – продукт для управления конфигурацией программ (Rational"s Software Configuration Management, SCM ), позволяющий производить версионный контроль всех документов проекта. С его помощью можно поддерживать несколько версий проектов одновременно, быстро переключаясь между ними. Rational Requisite Pro поддерживает обновления и отслеживает изменения в требованиях для группы разработчиков;
- SQA TeamTest – средство автоматизации тестирования ;
- Rational TestManager – система управления тестированием, которая объединяет все связанные с тестированием инструментальные средства, артефакты, сценарии и данные;
- Rational Robot – инструмент для создания, модификации и автоматического запуска тестов;
- SiteLoad, SiteCheck – средства тестирования Web-сайтов на производительность и наличие неработающих ссылок;
- Rational PerformanceStudio – измерение и предсказание характеристик производительности систем.
Этот набор продуктов постоянно совершенствуется и пополняется. Так, например, недавний продукт IBM Rational Software Architect (RSA) является частью IBM Software Development Platform – набора инструментов, поддерживающих жизненный цикл разработки программных систем. Продукт IBM Rational Software Architect предназначен для построения моделей разрабатываемых программных систем с использованием унифицированного языка моделирования UML 2.0, прежде всего моделей архитектуры разрабатываемого приложения. Тем не менее, RSA объединяет в себе функции таких программных продуктов, как Rational Application Developer, Rational Web Developer и Rational Software Modeler , тем самым предоставляя возможность архитекторам и аналитикам создавать различные представления разрабатываемой информационной системы с использованием языка UML 2.0, а разработчикам – выполнять разработку J2EE, XML, веб-сервисов и т.д.
Следуя принципам RUP, Rational Software Architect позволяет создавать необходимые модели в рамках рабочих процессов таких дисциплин, как:
- бизнес-анализ и моделирование ( Business modeling );
- управление требованиями (Requirements);
- анализ и проектирование (Analysis and Design);
- реализация (Implementation).
Кроме того, Rational Software Architect поддерживает технологию разработки, управляемой моделями (model-driven development, MDD), которая позволяет моделировать программное обеспечение на различных уровнях абстракции с возможностью трассируемости.
MSF (Microsoft Solution Framework)
В 1994 году, стремясь достичь максимальной отдачи от IT-проектов, Microsoft выпустила в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. Эти знания базируются на опыте, полученном Microsoft при работе над большими проектами по разработке и сопровождению программного обеспечения, опыте консультантов Microsoft и лучшем из того, что накопила на данный момент IT-индустрия. Все это представлено в виде двух взаимосвязанных и хорошо дополняющих друг друга областей знаний: Microsoft Solutions Framework (MSF) и Microsoft Operations Framework (MOF).
Следует отметить, что Microsoft разработала на базе общих методов MSF методики для прикладного и специализированного применения. Причем Microsoft сертифицирует экспертов именно по прикладным знаниям в применении MSF (например, сертификация MCTS 74-131 по экспертизе в методике управления проектами). Перед тем как изучать методы MSF, следует сначала определить, какой прикладной вариант MSF имеется в виду.
Наиболее популярные прикладные варианты MSF, разработанные Microsoft:
- методика внедрения решений в области управления проектами;
- методика управления IT-проектами на базе методологий MSF и Agile.
Важность прикладных вариантов MSF подчеркивает тот факт, что в "чистом варианте" саму методику MSF в своих IT-проектах компания Microsoft не использует. В проектах Microsoft Consulting Services применяется гибридная методология MSF и Agile. Несмотря на внешние существенные различия прикладных вариантов MSF, разработанных экспертами Microsoft, база методов MSF для них остается общей и отражает общие методологические подходы к итеративному ведению проектов.
MOF призван обеспечить организации, создающие критически важные (mission-critical) IT решения на базе продуктов и технологий Майкрософт, техническим руководством по достижению их надежности (reliability), доступности (availability), удобства сопровождения (supportability) и управляемости (manageability). MOF затрагивает вопросы, связанные с организацией персонала и процессов; технологиями и менеджментом в условиях сложных (complex), распределенных (distributed) и разнородных (heterogeneous) IT-сред. MOF основан на лучших производственных методиках, собранных в IT Infrastructure Library (ITIL), составленной Central Computer and Telecommunications Agency – Агентством правительства Великобритании.
Создание бизнес-решения в рамках отведенных времени и бюджета требует наличия испытанной методологической основы. MSF предлагает проверенные методики для планирования, проектирования, разработки и внедрения успешных IT-решений. Благодаря своей гибкости, масштабируемости и отсутствию жестких инструкций MSF способен удовлетворить нужды организации или проектной группы любого размера. Методология MSF состоит из принципов, моделей и дисциплин по управлению персоналом, процессами, технологическими элементами и связанными со всеми этими факторами вопросами, характерными для большинства проектов. MSF состоит из двух моделей и трех дисциплин. Они подробно описаны в 5 whitepapers. Начинать изучение MSF лучше с моделей (модель проектной группы, модель процессов), а затем перейти к дисциплинам (дисциплина управление проектами, дисциплина управление рисками, дисциплина управление подготовкой).
Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT-решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT-проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral). Модель процессов в MSF 3.0 была дополнена еще одним инновационным аспектом: она покрывает весь жизненный цикл создания решения, начиная с его отправной точки и заканчивая непосредственно внедрением. Такой подход помогает проектным группам сфокусировать свое внимание на бизнесотдаче (business value) решения, поскольку эта отдача становится реальной лишь после завершения внедрения и начала использования продукта.
Процесс MSF ориентирован на "вехи" (milestones) – ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата. Этот результат может быть оценен и проанализирован, что подразумевает ответы на вопросы: "Пришла ли проектная группа к однозначному пониманию целей и рамок проекта?", "В достаточной ли степени готов план действий?", "Соответствует ли продукт утвержденной спецификации?", "Удовлетворяет ли решение нужды заказчика?" и т. д.
Модель процессов MSF учитывает постоянные изменения проектных требований. Она исходит из того, что разработка решения должна состоять из коротких циклов, создающих поступательное движение от простейших версий решения к его окончательному виду.
Особенностями модели процессов MSF являются:
- подход, основанный на фазах и вехах;
- итеративный подход;
- интегрированный подход к созданию и внедрению решений.
Модель процессов включает такие основные фазы процесса разработки, как:
- выработка концепции (Envisioning);
- планирование (Planning);
- разработка (Developing);
- стабилизация (Stabilizing);
- внедрение (Deploying).
Кроме этого, существует большое количество промежуточных вех, которые показывают достижение в ходе проекта определенного прогресса и расчленяют большие сегменты работы на меньшие, обозримые участки. Для каждой фазы модели процессов MSF определяет:
- что (какие артефакты) является результатом этой фазы;
- над чем работает каждый из ролевых кластеров на этой фазе.
В рамках MSF программный код, документация, дизайн, планы и другие рабочие материалы создаются, как правило, итеративными методами. MSF рекомендует начинать разработку решения с построения, тестирования и внедрения его базовой функциональности. Затем к решению добавляются все новые и новые возможности. Такая стратегия именуется стратегией версионирования. Несмотря на то, что для малых проектов может быть достаточным выпуск одной версии, рекомендуется не упускать возможности создания для одного решения ряда версий. С созданием новых версий эволюционирует функциональность решения.
Итеративный подход к процессу разработки требует использования гибкого способа ведения документации. "Живые" документы (living documents) должны изменяться по мере эволюции проекта вместе с изменениями требований к конечному продукту. В рамках MSF предлагается ряд шаблонов стандартных документов, которые являются артефактами каждой стадии разработки продукта и могут быть использованы для планирования и контроля процесса разработки.
Решение не представляет бизнес-ценности, пока оно не внедрено. Именно по этой причине модель процессов MSF содержит весь жизненный цикл создания решения, включая его внедрение – вплоть до момента, когда решение начинает давать отдачу.
Аннотация.
Введение.
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) Если введено менее трех чисел, программа ждет дополнительного ввода.
Жизненный цикл ПО. Стадии и этапы
Жизненный цикл ИС - ряд событий, происходящих с системой в процессе ее создания и использования.
Стадия - часть процесса создания ПО, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта (моделей, программных компонентов, документации), определяемого заданными для данной стадии требованиями.
Жизненный цикл традиционно моделируется в виде некоторого числа последовательных этапов (или стадий, фаз). В настоящее время не выработано общепринятого разбиения жизненного цикла программной системы на этапы. Иногда этап выделяется как отдельный пункт, иногда - входит в качестве составной части в более крупный этап. Могут варьироваться действия, производимые на том или ином этапе. Нет единообразия и в названиях этих этапов.
Традиционно выделяются следующие основные этапы ЖЦ ПО:
Анализ требований,
Проектирование,
Кодирование (программирование),
Тестирование и отладка,
Эксплуатация и сопровождение.
Жизненный цикл ПО. Каскадная модель
каскадная модель (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++, функции не должны быть определены до момента их использования, но они должны быть ранее объявлены. Но даже после всего этого, в конце концов, эта функция должна быть определена. После этого прототип функции и ее определение связываются, и эта функция может быть использована.
Если функция ранее была объявлена, она должна быть определена с тем же возвращаемым значением и типами данных, в противном случае, будет создана новая, перегруженная функция. Заметьте, что имена параметров функции не должны быть одинаковыми.
