Жизненный цикл разработки по. Реферат: Жизненный цикл программного обеспечения

Жизненный цикл программного обеспечения

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт 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-го поколения;

· Внедрение. Разработчики обучают пользователей работе в среде новой ПО.

Аннотация.

Введение.

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

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

1. разработка;

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

3. сопровождение.

На фазе сопровождения, как правило, выполняются следующие виды работ:

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

При проведении разработки чётко выделяют следующие этапы:

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

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

§ каскадная модель

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

31. Техническое задание (ГОСТ 19.201 – 78). Его основные разделы и их содержание.

В соответствии с этим стандартом в техническое задание включаются следующие разделы:

2. введение;

3. основание для разработки;

4. назначение разработки;

5. требования к программному изделию;

6. требования к документации;

7. технико-экономические показатели;

8. стадии и этапы разработки;

9. порядок контроля и приёмки

10. приложение.

Введение:

§ наименование;

§ краткая характеристика в области применения ПО.

Основное назначение этого раздела – продемонстрировать актуальность данной разработки и какое место эта разработка занимает в ряду подобных.

Основание для разработки:

§ наименование документа, на основании которого ведётся разработка;

§ организация, утвердившая данный документ;

§ наименование или условное обозначение темы разработки.

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

Назначение разработки:

§ описание функционального и эксплуатационного назначения данной системы с указанием категории её пользователей.

Требования к программе или к программному изделию.

Этот раздел должен включать следующие подразделы:

1. требования к функциональным характеристикам;

2. требования к надёжности;

3. условия эксплуатации;

4. требования к составу и параметрам технических средств;

5. требования к информационной и программной совместимости;

6. требования к маркировке и упаковке;

7. требования к транспортированию и хранению.

8. специальные требования.

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

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

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

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

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

В разделе требования к маркировке и упаковке указываются способы маркировки и упаковки ПО.

В разделе требования к транспортированию и хранению указываются условия транспортирования, места хранения, условия складирования и сроки хранения в различных условиях.

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

Требования к программной документации.

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

Технико-экономические показатели.

Стадии и этапы разработки.

В нём указывают стадии и этапы разработки выполняемых работ с указанием сроков и исполнителей.

Порядок контроля и приёмки.

В нём указывают порядок проведения испытаний и общие требования по проведению приёмки.

Приложение: перечень НИР, обоснования, расчёты, и другие документы, которые следует использовать для разработки.

В зависимости от особенностей разрабатываемого ПО разрешается уточнять описанные разделы, вводить новые или объединять существующие.

32. Структурное проектирование ПО: метод структурного анализа, проектирование модульной структуры.

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

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

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

3. Принцип формализации заключается в необходимости строгого методологического подхода и решению проблемы.

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

5. Принцип полноты заключается в контроле на присутствие лишних элементов.

6. Принцип непротиворечивости заключается в обоснованности и согласованности элементов.

7. Принцип логической независимости заключается в концентрации внимания на логическом проектировании для обеспечения независимости от физического исполнения.

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

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

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

Для целей специфицирования систем в структурном анализе используются три группы средств, иллюстрирующих:

* функции, которые система должна выполнять;

* отношения между данными;

* зависящее от времени поведение системы (аспекты реального времени).

Для этого применяются:

* DFD (Data Flow Diagrams) – диаграммы потоков данных совместно со словарями данных и спецификациями процессов;

* ERD (Entity–Relationship Diagrams) – диаграммы сущность–связь;

* STD (State Transition Diagrams) – диаграммы переходов–состояний.

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

Структура каждого хранилища описывается с помощью ERD. В случае наличия реального времени DFD дополняется средствами описания, зависящего от времени поведения системы, которые описываются с помощью STD. Эти связи показаны на рисунке.

Взаимосвязь средств структурного анализа

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

К преимуществам разработки ПО с использованием модулей можно отнести следующее:

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

Для проектирования и документирования модульной структуры применяются структурные карты Константайна (Constantine), которые являются моделью отношений между программными модулями.

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

Элементы структурных карт.

Базовым элементом структурной карты является модуль. Можно выделить различные типы модулей:

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

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

3. Библиотека отличается от подсистемы тем, что определена вне контекста системы.

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

Типы модулей на структурных картах.

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

Для моделирования условных и циклических вызовов применяются условные и итерационные узлы.

Изображения условного и итерационного вызовов.

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

а - монолитная; б - последовательная; в - иерархическая; г – хаотическая.

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

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

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

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

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

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

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

– анализ требований;

– определение спецификаций;

– проектирование;

– кодирование;

– тестирование;

– сопровождение.

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

– Что должна делать программа?

– В чем состоят реальные проблемы, разрешению которых она должна способствовать?

– Что представляют собой входные данные?

– Какими должны быть выходные данные?

– Какими ресурсами располагает проектировщик?

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

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

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

Тестирование . На этом этапе производится всесторонняя проверка программ.

Сопровождение. Это этап эксплуатации системы. Каким бы изощренным ни было тестирование программ, к сожалению, в больших программных комплексах чрезвычайно тяжело устранить абсолютно все ошибки. Устранение обнаруженных при эксплуатации ошибок – первейшая задача этого этапа. Однако это далеко не все, что выполняется при сопровождении. Выполняемый в ходе сопровождения анализ опыта эксплуатации программы позволяет обнаруживать «узкие места» или неудачные проектные решения в тех или иных частях программного комплекса. В результате такого анализа может быть принято решение о проведении работ по совершенствованию разработанной системы. Сопровождение может также включать в себя проведение консультаций, обучение пользователей системы, оперативное снабжение пользователей информацией о новых версиях системы. Качественное проведение этапа сопровождения в большой степени определяет коммерческий успех программного продукта.

Тестирование . Существуют три аспекта проверки программы на:

– правильность;

– эффективность реализации;

– вычислительную сложность.

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

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

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

Первый способ основан на следующем правиле. Сложение и вычитание выполняются быстрее, чем умножение и деление. Целочисленная арифметика быстрее арифметики вещественных чисел. Таким образом, Х+Х лучше, чем 2*Х, где * – знак умножения. При выполнении операций над целыми числами следует помнить, что благодаря применению двоичной системы счисления умножение на числа, кратные двум, можно заменить соответствующим количеством сдвигов влево.

Второй способ заключается в удалении избыточных вычислений.

Третий способ проверки эффективности реализации основан на способности некоторых компиляторов строить коды для вычисления логических выражений так, что вычисления прекращаются, если результат становится очевидным. Например, в выражении A or В or С, если А имеет значение «истина», то переменные В и С уже не проверяются. Таким образом, можно сэкономить время, разместив переменные А, В, С так, чтобы первой стояла переменная, которая вероятнее всего будет истинной, а последней та, которая реже всего принимает истинное значение.

Четвертый прием – исключение циклов.

Пятый прием – развертывание циклов.

Это далеко не полный перечень способов оптимизации. Здесь приведены лишь самые очевидные из них. Следует, кроме того, заметить, что не всегда стоит увлекаться погоней за быстродействием, так как при этом чаще всего ухудшается удобочитаемость программ. В том случае, когда выигрыш получается «мизерный», вряд ли стоит предпочитать его ясности и читабельности программы.

Стандарты жизненного цикла ПО

ГОСТ 34.601-90
ISO/IEC 12207:1995 (российский аналог - ГОСТ Р ИСО/МЭК 12207-99)

Стандарт ГОСТ 34 .601-90

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

Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID ), получившей также от Т. Гилба в 70-е гг. название эволюционной модели . Также эту модель называют итеративной моделью и инкрементальной моделью .

Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации - получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение - инкремент - к его возможностям, которые, следовательно, развиваются эволюционно . Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения .

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

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

Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP , MSF , ).

Спиральная модель

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

На каждой итерации оцениваются:

риск превышения сроков и стоимости проекта;
необходимость выполнения ещё одной итерации;
степень полноты и точности понимания требований к системе;
целесообразность прекращения проекта.

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

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

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

В сегодняшней спиральной модели определён следующий общий набор контрольных точек :

Concept of Operations (COO) - концепция (использования) системы;
Life Cycle Objectives (LCO) - цели и содержание жизненного цикла;
Life Cycle Architecture (LCA) - архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;
Initial Operational Capability (IOC) - первая версия создаваемого продукта, пригодная для опытной эксплуатации;
Final Operational Capability (FOC) –- готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

Методологии разработки ПО

Microsoft Solutions Framework (MSF). Включает 4 фазы: анализ, проектирование, разработка, стабилизация, предполагает использование объектно-ориентированного моделирования.
Экстремальное программирование (англ. Extreme Programming, XP ). В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС. Разработка ведется с использованием последовательно дорабатываемых прототипов.
ЕСПД - комплекс государственных стандартов Российской Федерации, устанавливающих взаимосвязанные правила разработки, оформления и обращения программ и программной документации.

Литература

Братищенко В.В. Проектирование информационных систем. - Иркутск: Изд-во БГУЭП, 2004. - 84 с.
Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М .: Финансы и статистика, 2000.
Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. - М .: Интернет-университет информационных технологий - ИНТУИТ.ру, 2005.
Мишенин А.И. Теория экономических информационных систем. - М .: Финансы и статистика, 2000. - 240 с.

Примечания

Wikimedia Foundation . 2010 .

Смотреть что такое "Жизненный цикл программного обеспечения" в других словарях:

Период разработки и эксплуатации программного обеспечения, в котором обычно выделяют этапы: 1 возникновение и исследование идеи; 2 анализ требований и проектирование; 3 программирование; 4 тестирование и отладка; 5 ввод программы в действие; 6… … Финансовый словарь

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

жизненный цикл программного обеспечения - 3.7 жизненный цикл программного обеспечения; жизненный цикл ПО (software lifecycle): Последовательность следующих друг за другом процессов создания и использования программного обеспечения программируемой связанной с безопасностью здания или… …

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

Цикл программного обеспечения жизненный - Жизненный цикл программного обеспечения (software lifecycle): период времени, включающий в себя стадии: разработки требований к программному обеспечению, разработки программного обеспечения, кодирования, тестирования, интеграции, установки, а… … Официальная терминология

жизненный цикл - 4.16 жизненный цикл (life cycle): Развитие системы, продукта, услуги, проекта или других изготовленных человеком объектов, начиная со стадии разработки концепции и заканчивая прекращением применения. Источник … Словарь-справочник терминов нормативно-технической документации

Это процесс ее построения и развития. Жизненный цикл информационной системы период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в момент ее полного изъятия из… … Википедия

Жизненный цикл информационной системы это процесс ее построения и развития. Жизненный цикл информационной системы период времени, который начинается с момента принятия решения о необходимости создания информационной системы и заканчивается в… … Википедия, О. В. Казарин. В книге рассмотрены теоретические и прикладные аспекты проблемы зашиты программного обеспечения от различного рода злоумышленных действий. Особое внимание уделено моделям и методам создания…