Лекции по "Информатике"

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

Программное обеспечение не изнашивается.

Рис. 13.1 представляет коэффициент отказов как функцию времени для аппаратуры. Это связь, часто называемая «U-образная кривая», указывает, что аппаратура проявляет относительно высокий коэффициент отказов на раннем этапе её жизни (что связано с дефектами конструирования и производства), дефекты устраняются, и коэффициент отказов падает до установившегося уровня (обычно, очень низкого) на некоторый период времени. Однако, по прошествию времени коэффициент отказов опять возрастает, когда компоненты аппаратуры начинают портиться от пыли, вибрации, неправильной эксплуатации, перепадов температур и многих других «болезней» их окружения. Проще говоря, оборудование начинает изнашиваться.

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

Рис. 13.1. Кривая отказов для оборудования

Необнаруженные дефекты будут  вызывать частые отказы в раннем периоде  жизни программы. Однако, после того как они исправлены (хорошо, если без внесения других ошибок), кривая становится горизонтальной, как это  показано на рис. 13.2, является существенным упрощением реальной модели отказов программного обеспечения. Однако, вывод очевиден - программное обеспечение не изнашивается. Но оно ухудшается!

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

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

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

Рис. 13.3. Реальная кривая отказов программного обеспечения

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

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

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

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

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

Компоненты программного средства

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

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

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

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

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

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

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

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

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

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

Реальность: Книга стандартов может  существовать, но используется ли она? Осознают ли практикующие специалисты  её существование? Отражает ли она сегодняшнюю практику разработки? Она полна? Во многих случаях ответ на все эти вопросы «нет».

Миф: Мои люди действительно имеют  самые современные средства разработки. Более того, мы покупает им наиновейшие  компьютеры.

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

Миф: Если мы отстаём от графика, мы можем добавить программистов и догнать план (часто этот миф называется «принципом монгольской орды»).

Реальность: Разработка  программного  средства - не механический процесс, подобный промышленному производству. Согласно Бруксу, «добавление людей к опаздывающему проекту программного обеспечения делает его ещё более опаздывающим». Во-первых, это утверждение может показаться противоречащим интуиции. Однако, когда добавляются новые люди, люди, которые уже работали, должны тратить время на обучение новых коллег, тем самым уменьшая время, затрачиваемое на саму работу. Люди могут добавляться, но только запланированным и хорошо скоординированным образом.

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

Миф: Общее утверждение целей  является достаточным для того, чтобы  начать писать программы. Детали могут  быть уточнены позже.

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

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

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

Рис. 13.4. Влияние изменений

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

Миф: Раз уж мы написали программу и заставили её работать, наша работа выполнена.

Реальность: Кто-то однажды сказал, что «чем раньше вы начнете «писать  код», тем дольше вы будете писать его». Промышленные данные говорят о том, что от 50 до 70 % всех усилий, затрачиваемых на программу, будут потрачены после того, как программа будет представлена заказчику впервые.

Миф: До тех пор, пока я не заставлю программу «работать», я, по сути дела, не могу оценить её качества.

Реальность: Один из наиболее эффективных  механизмов обеспечения качества программного средства - это формальная техническая экспертиза. Экспертиза программного средства  является «фильтром качества», который, как считается, более эффективен, чем тестирование для нахождения определённых классов дефектов.