В.В. Кулямин - Технологии программирования. Компонентный подход (1133554), страница 16
Текст из файла (страница 16)
Из 20-ти участников этого проекта 5 (в том числеупомянутые выше 3 основных автора XP) опубликовали еще во время самого проекта и вдальнейшем 3 книги и огромное количество статей, посвященных XP. Этот проект неоднократноупоминается в различных источниках как пример использования этой методики [6,7,8].Приведенные ниже данные собраны на основе упомянутых статей [9], за вычетом неподтверждающихся сведений, и иллюстрируют проблемы некоторых техник XP при ихприменении в достаточно сложных проектах.Проект стартовал в январе 1995 года. С марта 1996 года, после включения в него Кента Бека,он проходил с использованием XP.
К этому времени он уже вышел за рамки бюджета и плановпоэтапной реализации функций. Команда разработчиков была сокращена, и в течение примернополугода после этого проект развивался довольно успешно. В августе 1998 года появилсяпрототип, который мог обслуживать около 10000 служащих. Первоначально предполагалось, чтопроект завершится в середине 1999 года и результирующее ПО будет использоваться дляуправления выплатами 87000 служащим компании. Он был остановлен в феврале 2000 года после4-х лет работы по XP в связи с полным несоблюдением временных рамок и бюджета.
СозданноеПО ни разу не использовалось для работы с данными о более чем 10000 служащих, хотя былопоказано, что оно справится с данными 30000 работников компании. Человек, игравший рольвключенного в команду заказчика в проекте, уволился через несколько месяцев такой работы, невыдержав нагрузки, и так и не получил адекватной замены до конца проекта.Литература к Лекции 3[1] У. Ройс. Управление проектами по созданию программного обеспечения. М.: Лори, 2002.[2] А.
Якобсон, Г. Буч, Дж. Рамбо. Унифицированный процесс разработки программногообеспечения. СПб.: Питер, 2002.[3] Kroll, The Spirit of the RUP. www-106.ibm.com/developerworks/rational/library/content/RationalEdge/dec01/ TheSpiritoftheRUPDec01.pdf[4] К. Бек. Экстремальное программирование. СПб.: Питер, 2002.[5] http://www.agilemanifesto.org/[6] K. Beck, et. al. Chrysler goes to “Extremes”. Distributed Computing, 10/1998.[7] A.
Cockburn. Selecting a Project’s Methodology. IEEE Software, 04/2000.[8] L. Williams, R. R. Kessler, W. Cunningham, R. Jeffries. Strengthening the Case for PairProgramming. IEEE Software 4/2000.[9] G. Keefer. Extreme Programming Considered Harmful for Reliable Software Development.AVOCA Technical Report, 2002.Доступен как http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf.47Лекция 4. Анализ предметной области и требования к ПОАннотацияРассматриваются вопросы, связанные с анализом предметной области и выделением требований кразрабатываемой программной системе, а также основные графические модели, используемые вэтих деятельностях — диаграммы потоков данных и вариантов использования.Ключевые словаАнализ предметной области, схема Захмана, модели предметной области, диаграммы потоковданных, диаграммы сущностей и связей, функции ПО, требования к ПО, варианты использования,действующие лица, диаграммы вариантов использования.Текст лекцииАнализ предметной областиДля того, чтобы разработать программную систему, приносящую реальные выгодыопределенным пользователям, необходимо сначала выяснить, какие же задачи она должна решатьдля этих людей и какими свойствами обладать.Требования к ПО определяют, какие свойства и характеристики оно должно иметь дляудовлетворения потребностей пользователей и других заинтересованных лиц.
Однакосформулировать требования к сложной системе не так легко. В большинстве случаев будущиепользователи могут перечислить набор свойств, который они хотели бы видеть, но никто не дастгарантий, что это — исчерпывающий список. Кроме того, часто сама формулировка этих свойствбудет непонятна большинству программистов: могут прозвучать фразы типа «должноиспользоваться и частотное, и временное уплотнение каналов», «передача клиента должна бытьмягкой», «для обычных швов отмечайте бригаду, а для доверительных — конкретных сварщиков»,и это еще не самые тяжелые для понимания примеры.Чтобы ПО было действительно полезным, важно, чтобы оно удовлетворяло реальныепотребности людей и организаций, которые часто отличаются от непосредственно выражаемыхпользователями желаний.
Для выявления этих потребностей, а также для выяснения смыславысказанных требований приходится проводить достаточно большую дополнительную работу,которая называется анализом предметной области или бизнес-моделированием, если речь идето потребностях коммерческой организации. В результате этой деятельности разработчики должнынаучиться понимать язык, на котором говорят пользователи и заказчики, выявить цели ихдеятельности, определить набор задач, решаемых ими. В дополнение стоит выяснить, какиевообще задачи нужно уметь решать для достижения этих целей, выяснить свойства результатов,которые хотелось бы получить, а также определить набор сущностей, с которыми приходитсяиметь дело при решении этих задач.
Кроме того, анализ предметной области позволяет выявитьместа возможных улучшений и оценить последствия принимаемых решений о реализации тех илииных функций.После этого можно определять область ответственности будущей программной системы —какие именно из выявленных задач будут ею решаться, при решении каких задач она можетоказать существенную помощь и чем именно. Определив эти задачи в рамках общей системызадач и деятельностей пользователей, можно уже более точно сформулировать требования к ПО.Анализом предметной области занимаются системные аналитики или бизнес-аналитики,которые передают полученные ими знания другим членам проектной команды, сформулировав ихна более понятном разработчикам языке. Для передачи этих знаний обычно служит некоторыйнабор моделей, в виде графических схем и текстовых документов.Анализ деятельности крупной организации, такой, как банк с сетью региональных отделений,нефтеперерабатывающий завод или компания, производящая автомобили, дает огромные объемыинформации.
Из этой информации надо уметь отбирать существенную, а также надо уметьнаходить в ней пробелы — области деятельности, информации по которым недостаточно для48четкого представления о решаемых задачах. Значит, всю получаемую информацию надо каким-тообразом систематизировать. Для систематизации сбора информации о больших организациях идальнейшей разработки систем, поддерживающих их деятельность, применяется схема Захмана(автор — John Zachman, [1,2]) или архитектурная схема предприятия (enterprise architectureframework).МотивацияЛюдиДанныеФункцииМестоВремяКонтекстМодель бизнесаСистемнаямодельТехнологическаямодельДетальноепредставлениеРаботающаяорганизацияСтратегия итактикаСтруктураорганизацииДанныеВыполняемые Географическоерасположение ифункциисетиПланыТаблица 5.
Схема Захмана. Приведены примеры моделей для отдельных клеток.В основе схемы Захмана лежит следующая идея: деятельность даже очень большойорганизации можно описать, используя ответы на простые вопросы — зачем, кто, что, как, где икогда, — и разные уровни рассмотрения. Обозначенные 6 вопросов определяют 6 аспектоврассмотрения.• Цели организации и базовые правила, по которым она работает.• Персонал, подразделения и другие элементы организационной структуры, связи междуними.• Сущности и данные, с которыми имеет дело организация.• Выполняемые организацией и различными ее подразделениями функции и операции надданными.• Географическое распределение элементов организации и связи между географическиразделенными ее частями.• Временные характеристики и ограничения на деятельность организации, значимые для еедеятельности события.Также выделены несколько уровней рассмотрения, из которых при бизнес-моделированииособенно важны три верхних.• Самый крупный — уровень организации в целом, рассматриваемой в ее развитиисовместно с окружением, уровень общего планирования ее деятельности.
Этот уровеньсодержит долговременные цели и задачи организации как цельной системы, основныесвязи организации с внешним миром и основные виды ее деятельности.49•Уровень бизнеса, на котором организация рассматривается во всех аспектах как отдельнаясущность, имеющая определенную структуру, которая соответствует ее основным задачам.• Системный уровень, на котором определяются концептуальные модели всех аспектоворганизации, без привязки к конкретным их воплощениям и реализациям, например,логическая модель данных в виде набора сущностей и связей между ними, логическаяархитектура системы автоматизации в виде набора узлов, с привязанными к нимфункциями и пр.Наиболее удобной формой представления информации при анализе предметной областиявляются графические диаграммы различного рода.
Они позволяют достаточно быстрозафиксировать полученные знания, быстро восстанавливать их в памяти и успешно объясняться сзаказчиками и другими заинтересованными лицами. Набросать рисунок из прямоугольников исвязывающих их стрелок обычно можно гораздо быстрее, чем записать соответствующий объеминформации, и на рисунке за один взгляд видно гораздо больше, чем в тексте. Изредкавстречаются люди, лучше ориентирующиеся в текстах и более адекватно их понимающие, но чащерисунки все же более удобны для иллюстрации мыслей и объяснения сложных вещей.Рисунок 16.
Схема деятельности компании в нотации Йордана-ДеМарко.Часто для описания поведения сложных систем и деятельности крупных организацийиспользуются диаграммы потоков данных (data flow diagrams). Эти диаграммы содержат 4 видаграфических элементов: процессы, представляющие собой любые трансформации данных врамках описываемой системы, хранилища данных, внешние по отношению к системе сущности ипотоки данных между элементами трех предыдущих видов.Используются несколько систем обозначений для перечисленных элементов, наиболееизвестны нотация Йордана-ДеМарко (Yourdon-DeMarco, [3,4]) и нотация Гэйна-Сарсона (GaneSarson, [5]), обе предложенные в 1979 году.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
