ВУЗ:
ложность этому, программное обеспечение не изнашивается, поэтому данный метод не подходит для оценки его качества.
Невозможность количественно измерить свойства программного обеспечения является одной из основных причин того, что
проектирование программного обеспечения до сих пор не нашло строгого обоснования в том смысле, как это имеет место при
проектировании в области механики или электротехники. В то время как эти предметы опираются на законы физики, технология
разработки программного обеспечения все еще находится на стадии поиска необходимых теоретических оснований. Фактически
современное состояние технологии разработки программного обеспечения напоминает нам состояние физики в начале семнадца-
того столетия, до того как Исаак Ньютон и другие ученые открыли, что такие фундаментальные свойства, как масса, ускорение и
сила, могут быть измерены и что между ними существует строгая математическая зависимость.
Поэтому в настоящее время исследования в области технологии разработки программного обеспечения разворачивают-
ся на двух уровнях. Исследователи-практики работают над развитием методов разработки, предназначенных для непосред-
ственного применения, тогда как исследователи-теоретики ведут поиск таких принципов и теорий, которые могут быть по-
ложены в основу будущей разработки более надежных технологических методов. Основанные на субъективных представле-
ниях, многие разработанные (и применяемые) в прошлом практиками методы были заменены другими подходами, которые
со временем также могут устареть. Между тем, успехи теоретиков остаются весьма относительными.
Прогресс в исследованиях как практиков, так и теоретиков имеет огромное значение. Жизнь нашего общества уже не-
возможна без использования компьютерных систем и связанного с ними программного обеспечения. Экономика, здраво-
охранение, государственные учреждения, законодательство, транспорт и оборона любого современного государства зависят
от больших систем программного обеспечения. Тем не менее надежность этих систем по-прежнему оставляет желать лучше-
го. Ошибки в программном обеспечении приводили к таким катастрофическим (или почти катастрофическим) последствиям:
принятие растущей луны за ядерную атаку, потеря 5 миллионов долларов банком Нью-Йорка только за один день, потеря
космическим кораблем "Маринер-18" сведений о пробах космического пространства, радиационное облучение людей, вы-
звавшее их смерть или паралич, или же нарушение работы телефонных линий в обширном географическом регионе.
В то время как наука продолжает поиск методов разработки качественного программного обеспечения, профессиональ-
ные организации пропагандируют высокие стандарты этики и профессионального поведения среди своих членов. Например,
Ассоциация по вычислительной технике (АСМ) и IEEE приняли кодекс профессионального поведения и этики, который на-
правлен на повышение профессионализма разработчиков программного обеспечения и предупреждение случаев их беспеч-
ного отношения к собственным разработкам.
В этой главе мы приводим некоторые результаты исследований в области технологии разработки программного обес-
печения, включающие как основные принципы (жизненный цикл программного обеспечения, модульность, шаблоны проек-
тирования), так и наиболее эффективные средства и методы разработки, используемые сегодня.
Вопросы для самопроверки
1. Почему количество строк в программе не определяет ее сложность?
2. С помощью какого метода можно определить, сколько ошибок содержится в определенной части программного
обеспечения?
3. Предложите метрику для оценки качества программного обеспечения. Какие слабые места она имеет?
6.2. ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Важнейшим понятием в технологии разработки программного обеспечения является жизненный цикл программы.
Жизненный цикл в целом. Жизненный цикл программы представлен на рис. 6.1. Здесь отражен тот факт, что, будучи
однажды
6.1. Жизненный цикл программы
созданной, программа входит в цикл, включающий ее использование и модификацию; продолжительность этого цикла рас-
пространяется на все время жизни программы. Такая картина характерна и для многих промышленных изделий. Отличие
заключается лишь в том, что для таких изделий фазу модификации точнее было бы назвать ремонтом или техническим об-
служиванием, поскольку они модифицируются по мере износа их частей.
Однако программы не подвержены износу. Поэтому они проходят фазу модификации из-за обнаружения ошибок, воз-
никновения изменений в области их применения, требующих внесения соответствующих корректировок в программы, или
из-за того, что прежняя модификация вызвала появление проблем в других частях программы. Например, изменения в нало-
говом законодательстве могут потребовать внесения корректировок в программы подготовки платежных ведомостей, свя-
занные с расчетом удерживаемого налога. Однако внесенные изменения, в свою очередь, могут неблагоприятно повлиять на
другие части программы, причем это может быть замечено не сразу.
Независимо от того, почему программа модифицируется, необходимо, чтобы некто (как правило, не автор ее исходной
версии) изучил и понял программу и ее документацию; если не всю программу, то хотя бы ту часть, которая относится к де-
лу. Любая модификация алгоритма программы может вызвать намного больше проблем, чем она предназначена решить.
Достижение необходимой степени понимания является сложной задачей, даже если программа правильно разработана и до-
кументирована. Фактически именно на этой стадии отдельные фрагменты программного обеспечения просто отбрасывают, исхо-
дя из утверждений (часто вполне справедливых), что проще разработать новую систему с нуля, чем успешно модифицировать
уже существующий пакет.
Страницы
- « первая
- ‹ предыдущая
- …
- 142
- 143
- 144
- 145
- 146
- …
- следующая ›
- последняя »
