Технология программирования стр.14

•    необходимость исправления ошибок, выявленных в процессе эксплуатации предыдущих версий;

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

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

На этом этапе в программный продукт вносят необходимые изменения, которые так же, как в остальных случаях, могут потребовать пересмотра проектных решений, принятых на любом предыдущем этапе. С изменением модели жизненного цикла программного обеспечения (см. далее) роль этого этапа существенно возросла, так как продукты теперь создаются итерационно: сначала выпускается сравнительно простая версия, затем следующая с большими возможностями, затем следующая и т. д. Именно это и послужило причиной выделения этапа сопровождения в отдельный процесс жизненного цикла в соответствии с стандартом 1SO/IEC 12207.

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

1.5. Эволюция моделей жизненного цикла программного обеспечения

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

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

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

•    простота планирования процесса разработки.

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

В целом необходимость возвратов на предыдущие стадии обусловлена следующими причинами:

•    неточные спецификации, уточнение которых в процессе разработки может привести к необходимости пересмотра уже принятых решений;

•    изменение требований заказчика непосредственно в процессе разработки;

•    быстрое моральное устаревание используемых технических и программных средств;

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

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


⇐ назад к прежней странице | | перейти на следующую страницу ⇒

Читайте также:

Яркая жизнь с компьютерными программами

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

Помоги себе сам

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

AlgoMusic M51 Galaxy - виртуальный инструмент на основе PD-синтеза

Виртуальный инструмент M51 Galaxy позволяет синтезировать "космические" звуки, обладает завораживающим звучанием. Обычно музыканты не очень жалуют инструменты, созданные с помощью SynthEdit. Однако M51, хоть и относится к их числу, действительно очень хорош. Секрет его звучания кроется в оригинальной архитектуре синтеза. На M51 Galaxy распространяется поговорка, что "все новое - это хорошо забытое старое". Идеи, заложенные в M51, уже были успешно реализованы в 80-х годах XX века.