В.В. Кулямин - Технологии программирования. Компонентный подход (1134162), страница 5
Текст из файла (страница 5)
В частности, она должнавключать достаточно полную и понятную пользователям документацию, возможно, также11специальную документацию для администраторов, а также набор документов для обученияработе с программой.• Ее низкая производительность на реальных данных приводит к значимым потерям дляпользователей.• Ее неправильная работа наносит ощутимый ущерб пользователям и другим организациям илицам, даже если сбои происходят не слишком часто.• Для выполнения своих задач она должна взаимодействовать с другими программами ипрограммно-аппаратными системами, работать на разных платформах.• Пользователи, работающие с ней, приобретают дополнительные выгоды от того, чтопрограмма развивается, в нее вносятся новые функции и устраняются ошибки. Необходимоналичие проектной документации, позволяющей развивать ее, возможно, вовсе не темразработчикам, которые ее создавали, без больших затрат на обратную разработку(реинжиниринг).• В ее разработку вовлечено значительное количество людей (более 5-ти человек).«Большую» программу практически невозможно написать с первой попытки, снебольшими усилиями и в одиночку.• Намного больше количество ее возможных пользователей, и еще больше тех лиц,деятельность которых будет так или иначе затронута ее работой и результатами.Примером «большой» программы может служить стандартная библиотека классов Java,входящая в Java Development Kit [1].Строго говоря, ни одно из указанных свойств не является обязательным для того, чтобыпрограмму можно было считать «большой», но при наличии двух-трех из них достаточноуверенно можно утверждать, что она «большая».На основании некоторых из перечисленных свойств можно сделать вывод, что «большая»программа или программная система чаще всего представляет собой не просто код илиисполняемый файл, а включает еще и набор проектной и пользовательской документации.Для разработки программных систем требуются особые методы — как уже говорилось, ихнельзя написать «нахрапом».
Изучением организационных, инженерных и технических аспектовсоздания ПО, включая методы разработки, занимается дисциплина, называемая программнойинженерией. Большая часть трудностей при разработке программных систем связана сорганизацией экономически эффективной совместной работы многих людей, приводящей кпрактически полезному результату. Это требует рассмотрения следующих аспектов.• Над программой обычно работает много людей, иногда географически удаленных друг отдруга и из различных организаций. Их работа должна быть организована так, чтобызатраты на разработку были бы покрыты доходами от продаж и предоставления услуг,связанных с полученной программой. В затраты входят зарплаты разработчиков, затраты назакупленное оборудование и программные инструменты разработки, на приобретениелицензий и патентование собственных решений, часто еще и затраты на исследованиепотребностей клиентов, проведение рекламы и другой маркетинговой деятельности.• Значимые доходы могут быть получены, только если программа будет предоставлятьпользователям в реальных условиях их работы такие возможности, что они готовы будутзаплатить за это деньги (которым, заметим, без труда можно найти другие полезныеприменения).
Для этого нужно учесть множество аспектов. Доходы от продаж значительноснизятся, если многие из пользователей не смогут воспользоваться программой толькопотому, что в их компьютерах процессоры слишком медленные или мало оперативнойпамяти, или потому что данные к системе часто поступают в искаженном виде и она неможет их обработать, или потому что они привыкли работать с графическим интерфейсом,а система требует ввода из командной строки, и т.п.Важно отметить, что практически полезная сложная программная система не обязательноявляется «правильной».12Большинство опытных разработчиков и исследователей считают, что практически значимыепрограммные системы всегда содержат ошибки.
При переходе от «небольших» программ к«большим» понятие «правильной» программы становится практически бессмысленным. Пропрограммную систему, в отличие от приведенной выше программы вычисления числа π, нельзяутверждать, что она «правильная», т.е. всегда правильно решает все поставленные перед нейзадачи. Этот факт связан как с практической невозможностью полного доказательства илипроверки этого, так и с тем, что смысл существования программной системы — удовлетворениепотребностей и запросов большого количества различных заинтересованных лиц. А этипотребности не только нечетко определены, различны для разных групп пользователей и иногдапротиворечивы, но и значительно изменяются с течением времени.В связи с этим, вместо рассмотрения «правильных» и «неправильных» программных систем, всилу практического отсутствия первых, рассматривают «достаточно качественные» и«недостаточно качественные».Поэтому и основные проблемы разработки сложных программных систем связаны снахождением разумного компромисса между затратами на разработку и качеством ее результата.В затраты входят все виды используемых ресурсов, из которых наиболее важны затрачиваемоевремя, бюджет проекта и используемый персонал.
Удовлетворение пользователей от работы спрограммой (а, следовательно, доходы от ее продаж и предоставления дополнительных услуг) иудовлетворение разработчиков от ее создания определяются качеством программы, котороевключает в себя такие аспекты, как набор предоставляемых возможностей, надежность, удобствоиспользования, гибкость, удобство внесения изменений и исправления ошибок. Более подробнопонятие качественного программного обеспечения будет обсуждаться в одной из следующихлекций.Часто программное обеспечение (ПО) нельзя рассматривать отдельно от программноаппаратной системы, куда оно входит в качестве составной части.
Изучением вопросов, связанныхс разработкой и эксплуатацией программно-аппаратных систем занимается системнаяинженерия. В ее рамки попадает огромное количество проблем, связанных с аппаратной частьюсистем и обеспечением нужного уровня интеграции программной и аппаратной составляющих.Мы только изредка будем затрагивать вопросы, касающиеся системной инженерии в целом, восновном ограничиваясь аспектами, относящимися непосредственно к ПО.В данном курсе будут рассматриваться различные подходы к решению проблем разработки,связанных с обеими составляющими дилеммы «ресурсы-качество» при создании сложныхпрограмм.
Для изложения этих подходов вводится система понятий, относящихся к программнымсистемам и процессам их создания и позволяющих эффективно разрабатывать такие системы,оценивать и планировать их свойства. В их число входят такие понятия, как жизненный цикл ПО,качество ПО, процесс разработки ПО, требования к ПО, архитектура ПО, образцыпроектирования и пр.Кроме того, особое внимание в курсе уделяется одному из подходов к разработке сложногоПО, компонентной разработке, предлагающей строить такие системы последовательно изотдельных элементов — компонентов, каждый из которых, в свою очередь, можетрассматриваться как отдельная программная система.
Курс дает введение в современныекомпонентные технологии разработки программных систем на основе платформ J2EE и .NET.Проблемы, связанные с управлением ресурсами разработки, в том числе — планированиемотдельных действий во времени, созданием эффективных команд разработчиков, относятся куправлению проектами, которому будет посвящена последняя лекция курса.На основании опыта конструирования больших систем разработаны так называемыетехнологические процессы, содержащие достаточно детальные описания разных аспектов ихсоздания и эксплуатации.
Эти описания дают ответы на вопросы о том, как должна вестисьразработка, какие лица должны в ней участвовать и на каких этапах, какие виды деятельности и вкакой последовательности должны выполняться, какие документы являются их входнымиданными и какие документы, модели, другие части программной системы должны бытьподготовлены в результате каждой отдельной работы. Элементы таких методик будут13упоминаться на всем протяжении курса. Также будут рассматриваться отраслевые стандарты,содержащие описание выработанных на основе большого количества реальных проектов подходовк построению сложных программных систем.При практической разработке больших систем, однако, стоит помнить, что всеобщеметодические рекомендации имеют границы применимости, и чем детальнее они определяютдействия разработчиков, тем вероятнее, что что-то пойдет не так, как это предусматриваетсяавторами методик.
Кроме того, огромное количество вспомогательных по сути документов,оформление которых часто требуется подобными методиками, иногда затрудняет пониманиеосновных целей проекта, принимаемых в его ходе решений и сути происходящего в нем. Онотакже может приводить к имитации усердной работы при отсутствии реальных продвижений кнужным результатам.Протест сообщества разработчиков против подобной бюрократизации разработки программ ипопыток механического использования теоретических рекомендаций вылился в популярноесейчас движение живой разработки ПО (Agile Software Development).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
