Программное обеспечение и его разработка - Фокс Джозеф М.

Схема трудности разработок. Таблицу 6.2 можно использовать как справочник, позволяющий определить, на что нужно обращать внимание, приступая к разработке системы. Расставленные в ней оценки «+», «-» — укажут вам, облегчает ли (-) данный фактор разработку или усложняет (+) ее при переходе от систем типов I и II к системам типов III, IV или V. Если на схеме отмечен знак (-), производительность труда будет повышаться, если стоит знак (+), производительность будет ниже. Сначала рассмотрите схему, а затем приступайте к изучению объяснений по каждому из 27 пунктов.

Функциональные факторы 1. Функции, количество Чем больше функций, тем больше нужно написать программ для их реализации. С ростом размеров программ трудность разработки программного обеспечения возрастает нелинейно. 2. Функции, сложность Программа вычисления коррекции орбиты для полета к Луне в 50 или более раз труднее, чем программа добавления очередного взноса за покупку в месячную кредитную карточку. Управляющие программы логически сложны, а логическая сложность представляет большую проблему, чем сложность научная. 3. Функции, ясность Некоторые функции (вспомните платежные ведомости) ясны и понятны. Другие находятся лишь в головах старых мастеров, и при попытке записать их на бумаге может возникнуть страшная путаница, а ведь без записи нельзя программировать. Особенно трудно работать с системами типа V. 4. Незамкнутый цикл, человек взаимодействует с работающей системой Системы, одним из элементов которых является человек, более сложны, чем какие-либо другие. Информацию для человека надо готовить особым образом; ответы, исходящие от него, надо приспосабливать к обстоятельствам; среди этих ответов может наблюдаться значительное разнообразие; человеку надо давать и дополнительную информацию, причем последовательность запросов нельзя сделать достаточно строгой, чтобы не получилось так, что он откажется от пользования системой. 5. Число различных пользователей программы Разные пользователи по-разному воздействуют и на вычислительную машину и на ее программное обеспечение. Стало аксиомой утверждение, что чем больше пользователей у программы, тем больше ошибок будет в ней обнаружено. Под пользователем понимается не просто отдельная вычислительная установка. Машины и программы для управления ракетами могут располагаться в сотнях различных мест, но способ использования у всех будет один и тот же. 6. Число запусков программы Если программа должна работать постоянно, нам надо позаботиться об эффективности (сколько аппаратуры необходимо для ее выполнения) в фазе использования. Если программа будет выполнена лишь единожды, ее эффективность не должна нас особенно волновать. 7. Число машин, на которых будет выполняться данная программа Если разрабатываемая программа будет выполняться только на одной машине, нам можно несколько меньше обращать внимания на используемые ею машинные ресурсы. Программа для радиолокатора, выполняемая на сотнях вычислительных машин, на сотнях кораблей, должна быть до предела отточена и сжата. Лишние затраты памяти будут умножаться в сотни раз. 8. Функции и их взаимодействия Некоторые сложные задачи весьма слабо взаимодействуют со всеми другими задачами, которые решаются на той же машине; другие же имеют настолько тесные связи, что оказываются буквально переплетенными. 9. Элементы данных Число и размеры элементов данных, их разнообразие, их взаимодействия, их изменчивость, все это может иметь огромное влияние на размер программы и на трудности, возникающие в фазе проектирования. Брукс замечает: «Покажите мне свои данные, и я смогу больше рассказать о вашей программе, чем в том случае, если мне покажут блок-схемы». 10. Ожидаемая частота внесения изменений в программу Если моя программа стабильна, т. е. изменяется не слишком часто, мне можно строить ее совершенна иначе, чем в том случае, когда я ожидаю, что она будет часто подвергаться изменениям. 11. Взаимодействие с другими системами Если наша вычислительная система должна полностью находиться в распоряжении каких-либо других систем, мы должны обязательна программировать так, чтобы учесть все типы возможных прерываний. ФАКТОРЫ ФАЗЫ ИСПОЛЬЗОВАНИЯ 12. Доступная мощность ЦП Для выполнения задания каждая программа использует ЦП. Некоторые программы используют его более эффективно, чем другие. Когда ресурсы ЦП оказываются недостаточными, программистов просят так провести проектирование программ, чтобы они не просто выполнили задание, но выполнил его с учетом заранее описанных ограничений недостаточных ресурсов ЦП. И программисты пробуют и проверяют свою работу, и пробуют снова и снова. Программы будут работать, но с точки зрения времени программирования, это стоит очень дорого. 13. Доступные пути ввода/вывода Логически эта проблема не отличается от работы в условиях недостатка ресурсов ЦП, но в данном случае наибольшая потребность возникает в числе путей, по которым данные передаются в машину и из нее. Много стараний должны приложить программисты, чтобы передать весь поток данных через небольшое число «портов», имеющихся в машине. 14. Доступная основная память Опять та же проблема, но уже со стороны памяти. Для хранения программ требуется память, а если памяти не хватает, программист должен «подкачивать» программы в основную память для выполнения и затем откачивать их во вспомогательную память. Для этого приходится затрачивать как время, так и опять-таки пространство. Может быть и другой вариант, в котором приходится втискиваться в отведенные рамки, создавая проект, а затем снова пытаются втиснуться в них. В 1946 году фон Нейман написал в одной из своих работ, что память является ключом к производительности. Это верно и в наши дни; скорость работы с памятью и ее объем есть критические величины. 15. Доступная вспомогательная память Еще раз та же самая проблема; на этот раз со стороны вспомогательной памяти. 16. Надежность/Последствия отказов Двухдневный отказ в системе типа I может быть вполне допустимым. Конечно, он причинит неудобства, но катастрофы за собой не повлечет. Однако, ни часовой, ни 10-минутный сбои нельзя допускать ни в системе управления авиалиниями, ни в системе управления полетом космического корабля, ни в системе противоракетной обороны. Если последствия отказов значительны, нельзя пользоваться стандартной операционной системой (распространяемой поставщиками аппаратуры). Та же проблема возникает и в системах реального времени. В этих случаях либо пишут новую операционную систему, либо модифицируют старую. 17. Ограничения реального времени Если печать платежной ведомости длится 2.5 ч. вместо запланированных 2 ч, кого это по-настоящему волнует? Возникает лишь легкая досада. Но, если радиолокатор поворачивается за 6.4 с, вычислительная машина обязана принять от него данные, закончив к этому времени обработку предыдущей порции. Если этого не будет, система переполнится. В системе реального времени стандартная операционная система применяться не может. Сколько разных объектов может отслеживаться одновременно? Сколько заданий необходимо завершить перед тем, как приступать к решению новой задачи? Чем больше возможностей и необходимости такого рода, тем больше приходится создавать системных программ для управления потоком данных и содержания его в порядке. Примеры: системы разделения времени; управляющие и командные системы; системы диспетчеризации воздушного транспорта. ФАКТОРЫ ФАЗЫ РАЗРАБОТКИ 18. Адекватность операционной системы Производители вычислительных машин обычно выпускают или сдают в аренду, или продают большие операционные системы вместе с аппаратурой, которая помогает распределять и управлять работой различных аппаратных компонентов вычислительной машины Однако эти операционные системы могут не вполне подходить для разработки программного обеспечения. 19. Время, выделенное на создание программного обеспечения Временной график становится доминирующим фактором в большинстве современных систем типа V. Причина кроется в том, что вычислительная машина и ее программное обеспечение обычно представляют собой лишь часть некоторой сложной системы. Спутники, корабли, оружие, ракеты, здания, фирмы — все это может задавать общий темп — а программное обеспечение должно быть готово одновременно с другими частями системы. Обычно график выдерживается — естественно за счет тех функций, которые надо выполнять. Сдается меньший набор функций, чем планировалось заранее, а недостающие вводятся в систему в более поздние сроки. 20. Доступность средств разработки Средства создания программного обеспечения, как и любой другой инструментарий, существенно воздействуют на производительность труда. Перед тем, как новую машину начнут использовать в качестве инструмента, ее тщательно изучают. Богатый набор мощных средств значительно повышает производительность труда. 21. Доступность машин для разработки программ Этот пункт имеет два аспекта. Во-первых, люди, строящие системы, понимают, что без вычислительной машины при разработке программного обеспечения обойтись очень трудно. Когда машины нет, либо она недостаточно мощна, все страшно замедляется. В то же время люди, незнакомые с ситуацией, не понимают того, что вычислительная машина представляет собой основное средство разработки во всем процессе создания программного обеспечения. Машина на стадии разработки используется столь же интенсивно, как и на стадии использования. Ну и конечно же машина необходима для тестирования программного обеспечения. 22. Знакомство группы, проводящей программирование, с аппаратурой Во всех областях человеческой деятельности нужно отводить время на приобретение опыта, это же относится и к программированию. Если наша группа программистов уже работала с данной аппаратурой, значит в прошлом она уже приобрела опыт, и от этой группы можно ожидать работы с большей производительностью труда. 23. Знакомство группы, проводящей программирование, с разработкой программного обеспечения Время на приобретение опыта, которое, как мы видели, нужно для работы с аппаратурой, нужно и для изучения инструментального программного обеспечения. 24. Число модулей Число модулей и связей между ними относится к ряду факторов, значительно влияющих на сложность выполняемой работы. Эта область сходна с пунктом «функции, их взаимодействия», но имеет и отличие от него в том смысле, что число модулей не обязательно связано с числом функций, поскольку количество модулей связано с методикой проектирования программ, а количество функций неотъемлемо от выполняемого задания. 25. Стабильность средств программного обеспечения Если средства создания программного обеспечения подвержены изменениям, этот и без того сложный процесс еще усложняется дополнительными, часто случайными проблемами. Примером может служить транслятор, в котором есть ошибки и который поэтому создает неправильные рабочие программы. 26. Стабильность аппаратуры Если используемая в фазе выполнения вычислительная машина находится в состоянии доводки, программисты часто не могут разобраться, где находится ошибка, в программе или в аппаратуре. Это вносит постоянную путаницу. Это, пожалуй, наихудшая из всех ситуаций, с которыми может столкнуться группа, разрабатывающая программное обеспечение. 27. Квалификация пользователя Пользователь есть настоящий заказчик и важнейшее звено группы разработки. Пользователь, ранее работавший с системой типа V, уже прошедший через весь этот процесс, является наилучшим из всех возможных партнеров разработчиков. Неопытный пользователь может полностью парализовать деятельность прекрасной группы разработчиков, поскольку новоиспеченные пользователи прокладывают себе дорогу к цели урывками.