Программное обеспечение и его разработка
Шрифт:
Простая деревянная зубочистка, как и молоток, упомянутый в гл.4, проходит всего два этапа. Вы ее делаете, используете и выбрасываете. Никакого ремонта не производится.
Существуют и программы типа «зубочистки», которые я пишу, выполняю, получаю удовлетворяющий меня результат и выбрасываю.
Молотки делают из металла. Мы делаем их и используем. Ремонт им не нужен, но пользуемся мы ими неоднократно.
Существуют программы типа «молотка». Их пишут, их доводят до работающего состояния и исполняют очень много раз. Как и молотки, они не требуют никаких модификаций, изменений или исправлений.
Существуют
Мы обратились к этим трем примерам постольку, поскольку они дают нам повод поговорить о качестве программного обеспечения Качество зубочисток необходимо только при их использовании. Для программ типа «зубочисток» нам не приходится заботиться о компоновке — до тех пор пока они работают на нас, — нам не нужно думать об их документировании, раз мы собираемся использовать их только однажды, а затем выбросить.
Качество молотка нас заботит больше, поскольку нам приходится использовать его продолжительное время. Не так уж много молотков ломается при первом же ударе, но плохо изготовленный молоток сломается гораздо быстрее, чем молоток, изготовленный из более хорошего материала и более старательно.
Так же обстоит дело и с программами типа «молотка». Чем дольше мы собираемся ими пользоваться, тем больше старания и затрат (имеются в виду прежде всего деньги) мы вкладываем в их изготовление, надеясь, что эти вложения оправдаются на этапе использования программ типа «молотка».
Заметьте, однако, что для этих программ мы не предусматриваем этапа модификаций (обслуживания). Поэтому документация необходима только для использования программ. До тех пор пока у нас есть хотя бы одна копия программы, написанная в форме, подходящей для ввода в машину, никакая документация на эту программу нам не нужна. Если программа правильна и не требует никаких изменений, все, что нам будет нужно, это инструкции, обращенные к пользователям.
Обращаясь теперь к программам типа «небоскребов», сразу же заметим, что если нам нужно добавить к небоскребу дополнительные помещения, то для оценки, планирования и выполнения всех работ пригодятся любые сведения о проложенных в здании водопроводных трубах, балках, электрических соединениях, проводах и еще о массе различных вещей. Нам будет нужна не пользовательская документация, а сведения о деталях конструкции, которые могут облегчить нам процесс перестройки.
Единственной причиной, по которой нам необходима документация на нашу программу типа «небоскреба», является то, что нам известно о предстоящих в будущем изменениях, а документация сильно облегчает этот процесс.
Это наиболее интересное утверждение; давайте обсудим его подробнее.
Если сформулировать это утверждение в негативной форме, то оно будет выглядеть так: если мы абсолютно уверены в том, что нам никогда не потребуется ни изменять, ни исправлять работающую для нас программу, то в виде, пригодном для чтения ее человеком, она нам никогда не понадобится.
Если бы мы были обладателями такой программы (а в настоящее время в мире достаточное число таких обладателей),
Конечно, временами мы бы волновались из-за того, что в программе могут быть скрытые дефекты или ошибки, или из-за того, что окружение программы меняется, и нам необходимо либо разбираться в структуре программы, либо писать полностью новую программу. Но, если все эти ужасы минуют нас стороной, пока мы находимся «у руля», мы можем сказать, что абсолютно удовлетворены работой нашей программы. Она выполнила свое дело, а мы этим остались довольны.
В настоящее время большинство программ в мире являются программами типа «небоскреба»; в них есть ошибки и недоработки, они нуждаются в модификации, чтобы не отставать от постоянно меняющегося окружения. Следовательно, как и проектировщикам, людям, проводящим модернизацию, необходимы синьки со схемами и документы, помогающие разобраться в причинах ошибок и исправлять их.
В здании, построенном согласно утвердившейся практике, обязательно должны быть предусмотрены вполне определенные коммуникации. Мы можем на это рассчитывать, а это облегчит нашу задачу перестройки.
Так же обстоит дело и с программным обеспечением. Если программисты и проектировщики исходной версии программы следовали «отработанным правилам», наша задача весьма и весьма облегчается. Даже сильнее, чем в строительстве, поскольку мы имеем дело с неосязаемыми вещами.
Существуют различные способы разделения процесса разработки программного обеспечения на этапы. При некоторых из них выделяют большее количество этапов, при других — меньшее. По-видимому, неизбежными являются шесть этапов.
Разработка программного обеспечения:
Определение требований
Проектирование
Написание команд программы
Компоновка
Тестирование
Документирование
Первый род деятельности, определение требований, представляет особую сложность для больших систем типа V, и вскоре мы его рассмотрим весьма подробно.
Проектирование, имеющееся в виду здесь, есть проектирование именно программ, а не той системы в целом, частью которой являются эти программы. Более глубокое изучение этого процесса мы проведем после того, как рассмотрим определение требований.
Третьим пунктом является написание команд, сведение проекта программного обеспечения или просто программы к последовательности машинных команд. Мы будем называть этот процесс программированием.
Компоновка представляет собой комбинирование, связывание отдельных частей программы, написанных разными людьми или группами, в одну большую систему программного обеспечения. Если в нашем распоряжении находятся 700 программистов, создающие отдельные программы, то задача «объединения» этих программ в одну систему может стать просто огромной, требующей много времени, дорогой и чреватой многими ошибками. Мы в дальнейшем увидим, что для компоновки систем из отдельных заранее написанных программ нужно создавать специальные инструментальные средства.