Источник нашей мудрости - наш опыт, источник нашего опыта - наша глупость.
В начале развития компьютерной индустрии проблема написания программ относилась к области искусства и состояла в том, чтобы получить "работающую" (доходящую до своего завершения) программу. Лишь затем программисты добивались от неё необходимых результатов путём длительной отладки и доработки. При этом было принято считать, что ни одна большая программа не может быть свободной от ошибок. Однако со временем появилось множество больших программ, которые должны были работать и работали годами, не выявляя никаких отклонений от требований. Но проходили годы, изменялась окружающая среда и изменялись требования. "Хорошие" работающие программы требовали модификации.
Важным толчком к совершенствованию методов разработки программ стало разделение пользователей на два класса: тех, кто пишет программы, и тех, кто решает с помощью этих программ прикладные задачи. Не будем забывать в первой группе так называемых системных программистов, которые пишут инструментальные программы (трансляторы, редакторы, операционные системы и т.п.) для других программистов. Таким образом программы стали отчуждаться от своих разработчиков. Они начали становиться самостоятельным продуктом.
Существенный качественный скачок стал возможен в семидесятых годах прошлого столетия. В 1969 году Эдсгер Дейкстра опубликовал статью "Структурное программирование" [3]. Это событие ознаменовало начало десятилетия напряжённого труда над инженерными методами, которые в корне изменили представления о подходах и тех возможностях, что открыты человеку в сфере разработки программного обеспечения (ПО). Благодаря структурному программированию и правильно поставленному процессу пошаговой разработки стало возможным создание действительно больших программных систем.
Расширение области применения вычислительной техники приводило к росту сложности ПО, ужесточению требования к надежности программ и, соответственно, росту времени построения программной системы и численности команды разработчиков. Возникла самостоятельная задача управления программными проектами, которая была разрешена путём построения методологии разработки программного обеспечения, включающей в себя описание процесса, организации работ, методов и инструментальных средств [4].
Проектирование любой программной системы включает в себя несколько этапов или процессов, и чем лучше поставлено управление проектом, тем ярче они выражены [5]. Методология проектирования программных систем описывает процесс создания и сопровождения программного обеспечения в виде жизненного цикла (ЖЦ) разработки, представляя его как некоторую последовательность стадий и выполняемых на них процессов.
Для каждого этапа определяются состав и последовательность выполняемых работ, критерии начала и завершения этапа, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ разработки позволяет спланировать и организовать процесс коллективной работы, а также обеспечить управление этим процессом.
Понятия жизненного цикла и модели жизненного цикла несколько отличаются, однако термин "жизненный цикл" часто используется в смысле "модели жизненного цикла". Модель жизненного цикла разработки ПО - обобщенная структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения типового программного продукта в течение всей жизни системы, т.е. от определения требований до завершения ее использования.
На данный момент можно выделить следующие часто упоминаемые и используемые модели жизненного цикла:
Каскадная модель (или, как ее еще называют, водопадная) (рис. 1.1) рассматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Эта модель происходит от структуры диаграммы Ганта для поэтапного процесса. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Модель подчеркивает, что результаты, полученные в ходе выполнения одного этапа, используются для выполнения следующего этапа.
(рис 1.1) Каскадная (водопадная) модель ЖЦ разработки
Марри Кантор [7] отмечает ряд важных аспектов, характерных для каскадной модели. Каскадная схема включает несколько важных операций, применимых ко всем проектам:
При разработке относительно простых программных систем каждое приложение представляло собой единый, функционально и информационно независимый блок. Для разработки такого типа приложений эффективным оказался каскадный способ. Каждый этап завершался после полного выполнения и документального оформления всех предусмотренных работ.
В результате можно выделить следующие положительные стороны применения каскадного подхода:
Каскадный подход хорошо зарекомендовал себя при построении простых систем, когда в самом начале разработки можно достаточно точно и полно сформулировать все требования к системе. Основным недостатком этого подхода является то, что, как показывает практика, реальный процесс создания сложной системы никогда полностью не укладывается в такую жесткую схему из-за большой динамики корректировок и уточнений, которые могут поступать как в результате дальнейшего развития проекта, так и извне в качестве новых требований и уточнений [9].
"Основное заблуждение каскадной модели состоит в предположениях, что проект проходит через весь процесс один раз, архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации устраняются по мере тестирования. Иными словами, каскадная модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит во время тестирования компонентов и системы" [10].
Порой для улучшения характеристик каскадной модели в нее включают возможность возвратов на ранее выполненные этапы (рис. 1.2). Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных стадиях разработки. Даже на уровне модели видно, что самыми трудоемкими являются возвраты на уровень уточнения исходных требований.
Одна из проблем такой модели ЖЦ разработки заключается в отсутствии возможности оценить конечный результат до завершения всего процесса разработки ПО. Как показывает практика, будущие пользователи охотнее вносят изменения и уточнения в ходе оценки какого-либо прототипа системы (которого в данной модели ЖЦ не строится).
(рис 1.2) Поэтапная модель с возвратами
Одним интересным вариантом развития поэтапной модели является V-образный жизненный цикл (рис. 1.3). В этой модели акцент делается на работы, связанные с верификацией документов разработки. Нисходящая ветвь модели описывает собственно разработку программной документации: требования к ПО, функции программных элементов, архитектуру - связи программных функций, программный код. Восходящая ветвь - этапы верификации.
Применение V-образной модели жизненного цикла позволяет сконцентрировать внимание на проверке результатов разработки, точно спланировать, какие свойства программного обеспечения будут исследоваться, на каких этапах и на основании какой документации. Обычно обращение к данному виду модели связано с повышенными требованиями к качеству результатов разработки. Именно такой подход к выбору модели жизненного цикла разработки характерен для бортовых авиационных систем, систем управления космическими аппаратами, разработки встроенного ПО.
(рис 1.3) V-образная модель жизненного цикла
Основная идея спиральной модели (рис. 1.4) заключается в том, что на этапах анализа и проектирования реализуемость технических решений и степень удовлетворения потребностей заказчика проверяется путём создания прототипов. Каждый виток спирали соответствует созданию работоспособного фрагмента или версии системы, в процессе анализа которых проводится конкретизация деталей проекта. В результате выбирается обоснованный вариант, который действительно удовлетворяет требованиям заказчика.
Итеративная разработка отражает объективно существующий спиральный цикл создания сложных систем. Она позволяет переходить на следующий этап, не дожидаясь полного завершения работы за счёт частичной реализации функциональности программного продукта. Тем самым активизируется процесс уточнения и дополнения требований со стороны пользователей системы.
(рис 1.4) Спиральная модель ЖЦ разработки
Стоит различать понятие модели жизненного цикла и жизненный цикл конкретного программного продукта. Конкретный программный проект обычно использует различные модели ЖЦ для различных компонент программного продукта. Некоторые компоненты могут быть заимствованы из предшествующих проектов или приобретены на рынке ПО, другие проходят итерационный спиральный или каскадный ЖЦ. На практике мы имеем дело со множеством параллельно протекающих процессов разработки, каждый из которых может находиться в состоянии, отличном от других (рис. 1.5).
Так, первая компонента разрабатывается по классическому жизненному циклу: требования, проектирование, реализация, интеграция. Вторая компонента - по сокращенному жизненному циклу. Третья относится к разряду приобретаемых или заимствованных компонент и потому проходит интеграционные испытания сразу после определения к ней требований.
Разработка четвертой компоненты явно определяется спиральным ЖЦ, в рамках которого последовательно реализуется два прототипа. На основании интеграционных исследований прототипов каждый раз производится уточнение требований. На третьем витке спирали, наконец, производится полномасштабное проектирование (создание документов описания архитектуры системы) и реализация окончательного варианта программной компоненты.
Применение процессной модели позволяет более точно отразить ход программной разработки, подчеркивая тот факт, что программный комплекс не однороден и содержит части, степень сложности которых сильно различается. Какие-то функции системы реализовались уже не один раз и могут использоваться практически без изменений в новых проектах. Другие требуют проведения исследовательских работ, многократного моделирования, оценки различных вариантов их реализации.
В общем случае следует отличать ЖЦ разработки ПО, который описывает именно процессы разработки, и ЖЦ самого ПО. В жизненном цикле проекта (разработки) присутствуют такие этапы, как формирование и обучение коллектива, закупка оборудования, создание стендов отладки и тестирования. ЖЦ программного продукта определяет, в свою очередь, процессы, связанные с функционированием самой программы, такие как:
Таким образом, можно и нужно говорить и о таком понятии, как ЖЦ проекта разработки ПО, который обычно на фазе инициализации включает в себя и подписание контракта с заказчиком, приобретение лицензий на инструментальное ПО, формирование среды информационной поддержки проекта, подбор и обучение персонала и т.п.
(рис 1.5) Процессная модель разработки программного обеспечения
Рассматривая разные подходы к процессу создания программного обеспечения, нельзя не упомянуть о таком, как метод формальных преобразований. Он заключается в автоматическом построении программы на основе ее формального описания, что гарантирует получение кода, который будет абсолютно точно соответствовать исходной спецификации.
Формальные преобразования - это набор методов, позволяющих математически корректно трансформировать исходные спецификации в код целевой программной системы. Т.к. переход от требований к коду происходит математически корректно, то проблема тестирования и доказательства корректности конечной программы по отношению к спецификации исчезает. Но верификация спецификаций по отношению к требованиям к системе остается.
Очевидно, что этот метод требует наличия формальных спецификаций, составление и доказательство корректности которых является нетривиальной задачей. Именно поэтому метод формальных преобразований редко используется для всего программного комплекса. В большинстве случаев он применяется для той части сложной системы и реализации тех алгоритмов, где исходные требования хорошо формализуемы.
Источник нашей мудрости - наш опыт, источник нашего опыта - наша глупость.
В начале развития компьютерной индустрии проблема написания программ относилась к области искусства и состояла в том, чтобы получить "работающую" (доходящую до своего завершения) программу. Лишь затем программисты добивались от неё необходимых результатов путём длительной отладки и доработки. При этом было принято считать, что ни одна большая программа не может быть свободной от ошибок. Однако со временем появилось множество больших программ, которые должны были работать и работали годами, не выявляя никаких отклонений от требований. Но проходили годы, изменялась окружающая среда и изменялись требования. "Хорошие" работающие программы требовали модификации.
Важным толчком к совершенствованию методов разработки программ стало разделение пользователей на два класса: тех, кто пишет программы, и тех, кто решает с помощью этих программ прикладные задачи. Не будем забывать в первой группе так называемых системных программистов, которые пишут инструментальные программы (трансляторы, редакторы, операционные системы и т.п.) для других программистов. Таким образом программы стали отчуждаться от своих разработчиков. Они начали становиться самостоятельным продуктом.
Существенный качественный скачок стал возможен в семидесятых годах прошлого столетия. В 1969 году Эдсгер Дейкстра опубликовал статью "Структурное программирование" [3]. Это событие ознаменовало начало десятилетия напряжённого труда над инженерными методами, которые в корне изменили представления о подходах и тех возможностях, что открыты человеку в сфере разработки программного обеспечения (ПО). Благодаря структурному программированию и правильно поставленному процессу пошаговой разработки стало возможным создание действительно больших программных систем.
Расширение области применения вычислительной техники приводило к росту сложности ПО, ужесточению требования к надежности программ и, соответственно, росту времени построения программной системы и численности команды разработчиков. Возникла самостоятельная задача управления программными проектами, которая была разрешена путём построения методологии разработки программного обеспечения, включающей в себя описание процесса, организации работ, методов и инструментальных средств [4].
Проектирование любой программной системы включает в себя несколько этапов или процессов, и чем лучше поставлено управление проектом, тем ярче они выражены [5]. Методология проектирования программных систем описывает процесс создания и сопровождения программного обеспечения в виде жизненного цикла (ЖЦ) разработки, представляя его как некоторую последовательность стадий и выполняемых на них процессов.
Для каждого этапа определяются состав и последовательность выполняемых работ, критерии начала и завершения этапа, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ разработки позволяет спланировать и организовать процесс коллективной работы, а также обеспечить управление этим процессом.
Понятия жизненного цикла и модели жизненного цикла несколько отличаются, однако термин "жизненный цикл" часто используется в смысле "модели жизненного цикла". Модель жизненного цикла разработки ПО - обобщенная структура, содержащая процессы, действия и задачи, которые осуществляются в ходе разработки, функционирования и сопровождения типового программного продукта в течение всей жизни системы, т.е. от определения требований до завершения ее использования.
На данный момент можно выделить следующие часто упоминаемые и используемые модели жизненного цикла:
Каскадная модель (или, как ее еще называют, водопадная) (рис. 1.1) рассматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Эта модель происходит от структуры диаграммы Ганта для поэтапного процесса. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Модель подчеркивает, что результаты, полученные в ходе выполнения одного этапа, используются для выполнения следующего этапа.
(рис 1.1) Каскадная (водопадная) модель ЖЦ разработки
Марри Кантор [7] отмечает ряд важных аспектов, характерных для каскадной модели. Каскадная схема включает несколько важных операций, применимых ко всем проектам:
При разработке относительно простых программных систем каждое приложение представляло собой единый, функционально и информационно независимый блок. Для разработки такого типа приложений эффективным оказался каскадный способ. Каждый этап завершался после полного выполнения и документального оформления всех предусмотренных работ.
В результате можно выделить следующие положительные стороны применения каскадного подхода:
Каскадный подход хорошо зарекомендовал себя при построении простых систем, когда в самом начале разработки можно достаточно точно и полно сформулировать все требования к системе. Основным недостатком этого подхода является то, что, как показывает практика, реальный процесс создания сложной системы никогда полностью не укладывается в такую жесткую схему из-за большой динамики корректировок и уточнений, которые могут поступать как в результате дальнейшего развития проекта, так и извне в качестве новых требований и уточнений [9].
"Основное заблуждение каскадной модели состоит в предположениях, что проект проходит через весь процесс один раз, архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации устраняются по мере тестирования. Иными словами, каскадная модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит во время тестирования компонентов и системы" [10].
Порой для улучшения характеристик каскадной модели в нее включают возможность возвратов на ранее выполненные этапы (рис. 1.2). Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных стадиях разработки. Даже на уровне модели видно, что самыми трудоемкими являются возвраты на уровень уточнения исходных требований.
Одна из проблем такой модели ЖЦ разработки заключается в отсутствии возможности оценить конечный результат до завершения всего процесса разработки ПО. Как показывает практика, будущие пользователи охотнее вносят изменения и уточнения в ходе оценки какого-либо прототипа системы (которого в данной модели ЖЦ не строится).
(рис 1.2) Поэтапная модель с возвратами
Одним интересным вариантом развития поэтапной модели является V-образный жизненный цикл (рис. 1.3). В этой модели акцент делается на работы, связанные с верификацией документов разработки. Нисходящая ветвь модели описывает собственно разработку программной документации: требования к ПО, функции программных элементов, архитектуру - связи программных функций, программный код. Восходящая ветвь - этапы верификации.
Применение V-образной модели жизненного цикла позволяет сконцентрировать внимание на проверке результатов разработки, точно спланировать, какие свойства программного обеспечения будут исследоваться, на каких этапах и на основании какой документации. Обычно обращение к данному виду модели связано с повышенными требованиями к качеству результатов разработки. Именно такой подход к выбору модели жизненного цикла разработки характерен для бортовых авиационных систем, систем управления космическими аппаратами, разработки встроенного ПО.
(рис 1.3) V-образная модель жизненного цикла
Основная идея спиральной модели (рис. 1.4) заключается в том, что на этапах анализа и проектирования реализуемость технических решений и степень удовлетворения потребностей заказчика проверяется путём создания прототипов. Каждый виток спирали соответствует созданию работоспособного фрагмента или версии системы, в процессе анализа которых проводится конкретизация деталей проекта. В результате выбирается обоснованный вариант, который действительно удовлетворяет требованиям заказчика.
Итеративная разработка отражает объективно существующий спиральный цикл создания сложных систем. Она позволяет переходить на следующий этап, не дожидаясь полного завершения работы за счёт частичной реализации функциональности программного продукта. Тем самым активизируется процесс уточнения и дополнения требований со стороны пользователей системы.
(рис 1.4) Спиральная модель ЖЦ разработки
Стоит различать понятие модели жизненного цикла и жизненный цикл конкретного программного продукта. Конкретный программный проект обычно использует различные модели ЖЦ для различных компонент программного продукта. Некоторые компоненты могут быть заимствованы из предшествующих проектов или приобретены на рынке ПО, другие проходят итерационный спиральный или каскадный ЖЦ. На практике мы имеем дело со множеством параллельно протекающих процессов разработки, каждый из которых может находиться в состоянии, отличном от других (рис. 1.5).
Так, первая компонента разрабатывается по классическому жизненному циклу: требования, проектирование, реализация, интеграция. Вторая компонента - по сокращенному жизненному циклу. Третья относится к разряду приобретаемых или заимствованных компонент и потому проходит интеграционные испытания сразу после определения к ней требований.
Разработка четвертой компоненты явно определяется спиральным ЖЦ, в рамках которого последовательно реализуется два прототипа. На основании интеграционных исследований прототипов каждый раз производится уточнение требований. На третьем витке спирали, наконец, производится полномасштабное проектирование (создание документов описания архитектуры системы) и реализация окончательного варианта программной компоненты.
Применение процессной модели позволяет более точно отразить ход программной разработки, подчеркивая тот факт, что программный комплекс не однороден и содержит части, степень сложности которых сильно различается. Какие-то функции системы реализовались уже не один раз и могут использоваться практически без изменений в новых проектах. Другие требуют проведения исследовательских работ, многократного моделирования, оценки различных вариантов их реализации.
В общем случае следует отличать ЖЦ разработки ПО, который описывает именно процессы разработки, и ЖЦ самого ПО. В жизненном цикле проекта (разработки) присутствуют такие этапы, как формирование и обучение коллектива, закупка оборудования, создание стендов отладки и тестирования. ЖЦ программного продукта определяет, в свою очередь, процессы, связанные с функционированием самой программы, такие как:
Таким образом, можно и нужно говорить и о таком понятии, как ЖЦ проекта разработки ПО, который обычно на фазе инициализации включает в себя и подписание контракта с заказчиком, приобретение лицензий на инструментальное ПО, формирование среды информационной поддержки проекта, подбор и обучение персонала и т.п.
(рис 1.5) Процессная модель разработки программного обеспечения
Рассматривая разные подходы к процессу создания программного обеспечения, нельзя не упомянуть о таком, как метод формальных преобразований. Он заключается в автоматическом построении программы на основе ее формального описания, что гарантирует получение кода, который будет абсолютно точно соответствовать исходной спецификации.
Формальные преобразования - это набор методов, позволяющих математически корректно трансформировать исходные спецификации в код целевой программной системы. Т.к. переход от требований к коду происходит математически корректно, то проблема тестирования и доказательства корректности конечной программы по отношению к спецификации исчезает. Но верификация спецификаций по отношению к требованиям к системе остается.
Очевидно, что этот метод требует наличия формальных спецификаций, составление и доказательство корректности которых является нетривиальной задачей. Именно поэтому метод формальных преобразований редко используется для всего программного комплекса. В большинстве случаев он применяется для той части сложной системы и реализации тех алгоритмов, где исходные требования хорошо формализуемы.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.