3-software_engineering_construction (1133543), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

Это подразумевает “лишь”придание большей значимости читаемости кода, простоте тестирования, приемлемому уровнюпроизводительности и удовлетворению заданных критериев, вместо постоянногосовершенствования кода, не оглядываясь на сроки, функциональность и другие характеристики иограничения проекта.Минимизация сложности достигается, в частности, следованием стандартам (обсуждаются в теме1.4 “Стандарты в конструировании”), использованием ряда специфических техник (освещаются в 3.3“Кодирование”) и поддержкой практик, направленных на обеспечение качества в конструировании(3.5 “Качество конструирования”).1.2 Ожидание изменений (Anticipating Changes)Большинство программных систем изменяются с течением времени. Причин этому – множество.Ожидание изменений является одной из движущих сил конструирования программного обеспечения.Программное обеспечение не является изолированным от внешнего окружения (как системного, таки с точки зрения области деятельности, для автоматизации задач и проблем которого оноприменяется).

Более того, программные системы являются частью изменяющейся среды и должныменяться вместе с ней, а, иногда, и быть источником изменений самой среды.Ожидание изменений поддерживается рядом техник, представленных в теме 3.3 “Кодирование”.1.3 Конструирование с возможностью проверки (Constructing for Verification)“Конструирование для проверки” (а именно такой смысл заложен в оригинальное название даннойтемы) предполагает, что построение программных систем должно вестись таким образом, чтобысама программная система помогала вести поиск причин сбоев, будучи прозрачной для примененияразличных методов проверки (и, кстати, внесения необходимых изменений), как на стадиинезависимого тестирования (например, инженерами-тестировщиками), так и в процессеоперационной деятельности - эксплуатации, когда особенно важна возможность быстрогообнаружения и исправления возникающих ошибок.Среди техник, направленных на достижение такого результата конструирования: обзор, оценка кода (code review) модульное тестирование (unit-testing) структурирование кода для и совместно с применениям автоматизированных средствтестирования (automated testing) ограниченное применение сложных или тяжелых для понимания языковых структур1.4 Стандарты в конструировании (Standards in Constructing)Стандарты, которые напрямую применяются при конструировании, включают: коммуникационные методы (например, стандарты форматов документов и <оформления>содержания) языки программирования и соответствующие стили кодирования (например, Java LanguageSpecification, являющийся частью стандартной документации JDK – Java Development Kit иJava Style Guide, предлагающий общий стиль кодирования для языка программированияJava) платформы (например, стандарты программных интерфейсов для вызовов функцийоперационной среды, такие как прикладные программные интерфейсы платформы Windows -Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru4Основы программной инженерии (по SWEBOK)Программная инженерия.

Конструирование программного обеспечения.Win32 API, Application Programming Interface или .NET Framework SDK, Software DevelopmentKit)инструменты (не в терминах сред разработки, но возможных средств конструирования –например, UML как один из стандартов для определения нотаций для диаграмм,представляющих структура кода и его элементов или некоторых аспектов поведения кода)Использование внешних стандартов. Конструирование зависит от внешних стандартов, связанныхс языками программирования, используемым инструментальным обеспечением, техническимиинтерфейсами и взаимным влиянием Конструирования программного обеспечения и другихобластей знаний программной инженерии (в том числе, связанных дисциплин, например, управленияпроектами).

Стандарты создаются разными источниками, например, консорциумом OMG – ObjectManagement Group (в частности. Стандарты CORBA, UML, MDA, …), международнымиорганизациями по стандартизации такими, как ISO/IEC, IEEE, TMF, …, производителями платформ,операционных сред и т.д. (например, Microsoft, Sun Microsystems, CISCO, NOKIA, …),производителями инструментов, систем управления базами данных ит.п. (Borland, IBM, Microsoft,Sun, Oracle, ...). Понимание этого факта позволяет определить достаточный и полный наборстандартов, применяемых в проектной команде или организации в целом.Использование внутренних стандартов.

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

Управление конструированием (Managing Construction)2.1 Модели конструирования (Construction Models)Модели конструирования определяют комплекс операций, включающих последовательность,результаты (например, исходный код и соответствующие unit-тесты) и другие аспекты, связанные собщим жизненным циклом разработки. В большинстве случаев, модели конструированияопределяются используемым стандартом жизненного цикла, применяемыми методологиями ипрактиками. Некоторые стандарты жизненного цикла, по своей природе, являютсяориентированными на конструирование – например, экстремальное программирование (XP- eXtremeProgramming). Некоторые рассматривают конструирование в неразрывной связи с проектированием(в части моделирования), например, RUP (Rational Unified Process).Создано множество моделей разработки программного обеспечения.

Ряд из них в большей степенисфокусирован на конструировании программного обеспечения, как таковом.Некоторые модели являются более линейными с точки зрения конструирования ПО. К нимотносятся, например, водопадная (waterfall) и поэтапная (staged-delivery) модели жизненного цикла(моделям жизненного цикла посвящена специальная глава, написанная Сергеем Орликом какважное расширение SWEBOK). Эти модели рассматривают конструирование как деятельность,которая начинает проводиться только после завершения определенных обязательных к выполнению(prerequisite) работ, включающих детальное определение требований, подробный дизайн идетальное планирование. Более линейные подходы стараются подчеркнуть действия,предваряющие конструирование (т.е. требования и дизайн) и создать более четкое разделениемежду такими различными типами деятельности. В таких моделях основным содержаниемконструирования может быть кодирование.Другие модели более итеративны, к ним относятся – эволюционное прототипирование,экстремальное программирование и Scrum.

Эти подходы сходятся к рассмотрению конструированиякак деятельности, которая ведется одновременно с другими видами работ по созданиюпрограммного обеспечения и пересекаясь с ними (видимо, здесь имеется в виду взаимозависимостьCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru5Основы программной инженерии (по SWEBOK)Программная инженерия. Конструирование программного обеспечения.и влияние друг на друга), включая определение требований, проектирование и планирование. Этиподходы смешивают проектирование, кодирование и тестирование, часто рассматривая ихкомбинацию как конструирование.Соответственно, что именно подразумевается под “конструированием” зависит в определеннойстепени от используемой модели жизненного цикла.2.2 Планирование конструирования (Construction Planning)Выбор метода (методологии) конструирования является ключевым аспектом для планированияконструкторской деятельности. Такой выбор значим для всей конструкторской деятельности, а такженеобходимых условий еѐ осуществления, определяя порядок соответствующих операций и уровеньвыполнения заданных условий перед тем как начнется конструирование или составляющие егодействия.

Например, модульное тестирование в ряде методов является частью работ, посленаписания соответствующего функционального кода, в то время, как ряд гибких (agile) практик,например, XP (кстати, первыми начавшие использовать такие методы верификации кода), требуютнаписания Unit-тестов до того, как пишется соответствующий код, требующий тестирования.Используемый подход к конструированию влияет на возможность уменьшения (в идеале минимизации) сложности, готовности к изменениям и конструировании с возможностью проверки.Планирование конструкторской деятельности определяет порядок, в котором создаются компонентыи другие активы данной области знаний (фазы деятельности), проводятся работы по обеспечениюкачества получаемого программного обеспечения, распределяются* задачи и соответствующиересурсы, в том числе, определяются назначения/отображения работ конкретным инженерампрограммистам, членам проектной группы.

Все это, конечно, происходит, следуя правилам,определяемым используемым методом (методологией, практиками и т.п.).*Заметьте – не распределяют, а распределяются, подразумевая процесс, приводящий кобеспечению явной связи между задачей и ресурсами. В нечетко регламентированных (это ни в коемслучае не ругательство, это определение – ведь существует же понятие нечѐткая логика,неструктурированные базы данных, например, в отношении нереляционных систем и т.п.) инеформальных методах, таких, как XP, члены проектной группы сами принимают на себяответственность по решению определенных задач, а “владение” кодом является совместным наоснове сотрудничества, как одного из ключевых принципов работы проектной команды.2.3 Измерения в конструировании (Construction Measurement)Большая часть результатов, да и самой деятельности по конструированию программногообеспечения, может быть измерена, в том числе - количественно.

Это и исходный разработанныйкод, и модифицированный объем кода, и степень повторного использования, и многие другиехарактеристики. Эти измерения, или как их еще принято называть – результаты аудита кода иметрики кода, несут большую пользу как для оценки рисков и качества (приводящих ксоответствующим операциям по снижению рисков и повышению качества), а также, для управленияконструированием и программными проектами, в целом. О каком планировании может идти речь,если мы не способны предсказать (например, на основе оценки результатов предыдущих проектов)ни длительность работ, ни стоимость отдельных задач, ни вероятность возникновения дефектовпротив заданных параметров приемлемого качества?Код является одним из наиболее четко детерминированных активов проекта (постепенно такимистановятся и модели, строящиеся на основе структур метаданных, и тесно связанные с кодом например, UML).

Код является и самим носителям требуемой функциональности. Соответственно,применение измерений в отношении кода становится тем инструментом, который влияет и науправление и на сам код.Последнее время, большое внимание многие профессиональные разработчики, то есть инженерыконструкторы программного обеспечения, уделяют рефакторинг кода, как методы егореструктурирования, призванные без изменения содержания (то есть функциональности ифункциональной целостности) обеспечить решение задач минимизации сложности, готовности кизменениям (гибкости), прозрачности документирования и многих других актуальных аспектовCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru6Основы программной инженерии (по SWEBOK)Программная инженерия.

Характеристики

Список файлов книги