Читайте также:
|
Введение
Методология разработки ПО – это набор правил и практик, используемых для создания компьютерных программ.
Тяжеловесные методологии (heavyweight methodology) имеют много правил и практик и документов. Требуется жёсткая дисциплина для того чтобы следовать всему этому достаточно чётко.
Легковесная методология (lightweight methodology) вводит всего несколько правил и практик, причём только те из них, которым легко следовать.
В конце 1960 – начале 1970ых годов написание программ представляло собой хаотических процесс, когда программисты просто писали программы, мало задумываясь о том что эти программы переживут их. Программы получались настолько сложными, что никто, кроме их авторов не мог в них разобраться. В то время оказывалось чудом, если программа вообще работала без большого числа ошибок. Таким образом, заставить работать программу, особенно более-менее большую и сложную, было похоже на приключение.
Позже, постепенно стали появляться методологии. Многие из которых наивно предполагали, что если расписать все действия программистов, а так же иных лиц, задействованных в разработке ПО, то можно будет создавать сложные программные системы, наподобие того, как строятся сложные здания и другие архитектурные сооружения. Стала возникать дисциплина – программная инженерия. Так возникло большое количество тяжёлых методологий, разработка ПО постепенно обросла большим количеством документации, проведением совещаний, утверждений и согласований. В конечном счёте, случилось так, что на поддержание методологий в актуальном состоянии и на контроль работы в соответсвие с этими методологиями уходило значительно больше ресурсов, чем непосредственно на создание программы, которая и нужна была заказчику. Важно понимать – конечному пользователю не нужна куча бумаг, документов, диаграмм и планов – ему нужна работающая программа, которая решает его текущие задачи. Кроме того, тяжёлые методологии плохо (а порой совсем) не учитывали человеческий фактор. Так, например, программистам нравится писать программы, а вовсе не кучу сопроводительной документации и руководств пользователя, которую, особенно в условиях часто меняющихся требований, приходиться поддерживать в актуальном состоянии.
Последние тенденции в автоматизации бизнеса показывают, что одним из критических аспектов современных бизнес процессов является их большая изменчивость. Как следствие, ПО, которое их автоматизирует, должно адекватно реагировать на эти изменения. Проблема усугубляется тем, что часто требования меняются в процессе разработки системы, и, как только система входит в промышленную эксплуатацию, она уже оказывается устаревшей.
Эти условия привели к тому, что в последнее время для разработки автоматизированных систем для бизнеса всё чаще предпочтение отдаётся не тяжеловесным процессам, требующим большого объёма документации и других вспомогательных процессов и задач, что приводит как к удорожанию конечного продукта, так и, что наиболее важно, в увеличенному времени его создания, т.е. к плохому удовлетворению требования Time To Market, а более лёгким (или гибким, Agile) методологиям. Одной из таких методологий является Экстремальное Программирование.
Экстремальное программирование, несмотря на своё название, представляет собой весьма строгую и дисциплинированную методологию построения жизненного цикла ПО. Эта методология существует уже более 8 лет и уже доказала свою эффективность во многих компаниях и больших и маленьких.
Основной причиной успеха XP является его ориентированность на удовлетворённость заказчика. Основной принцип методологии – это доставка того ПО которых хочет заказчик и тогда когда он в нём нуждается. XP позволяет разработчикам реагировать на изменение требований заказчиком даже на поздих этапах его жизненного цикла.
Кроме того методология делает упор на командной работе. Менеджеры, заказчики и разработчики – все являются частью одной команды целью которой является создание и поставка качественного ПО.
XP улучшает проектные работы четырьмя способами:
Практики XP
В основе экстремального программирования лежит ряд практик. Условно их можно разделить на 4 группы:
Каждая группа включает в себя несколько практик.
Планирование
Дизайн
Кодирование
Тестирование
Конфигурационное управление (Software Configuration Management)
Несмотря на то, что создание программ во многом является творческим процессом, создание программных продуктов, тем не менее, стремится к довольно чёткой организации, так как принципиальным отличием программного продукта от простой (или сложной) программы создаваемой одним программистом для себя является то, что в этом процессе принимает большое количество людей, не только программистов. Это: руководящий состав, заказчики, системные аналитики, специалисты по технологии, по технической поддержке, тестировщики. Деятельность всех этих людей необходимо организовывать. Этим занимается инженерия программного обеспечения. Одним из её важных разделов является управление конфигурацией.
Коротко SCM (Software Configuration Management) можно определить как организация компонентов программной системы таким образом, чтобы они соответствовали один другому в рабочем процессе и функционировали синхронно.
Другим, более полным определением является данное Прессманом в своей книге [25]: совокупность операций, предназначенных для контроля изменений путём идентификации рабочих продуктов, которые вероятнее всего подверглись изменению, установлению взаимосвязи между ними, определения механизмов для управления различными версиями этих рабочих продуктов, контролирования назначенных изменений, а так же проверки и регистрации выполненных изменений.
Процесс конфигурационного управления задействован на ВСЕХ этапах жизненного цикла программного продукта, начиная от обследования организации и выработки концепции системы, и заканчивая выводом системы из эксплуатации. Так на этапе обследования, как правило, появляется большое количество документов, схем, переписки, протоколов совещаний. Всё это подлежит управлению с точки зрения конфигурации, что бы как в процессе работы над этими документами, так и позже, всегда иметь возможность получить доступ к наиболее актуальной их версии. На этапе кодирования, большое внимание уделяется версиям исходного кода. На этапе сопровождения, особенно при наличии нескольких параллельных версий системы (например, для разных целевых платформ или разных заказчиков), важно чётко знать какой элемент конфигурации входит в конкретную конфигурацию. Например, для того, чтобы оценить последствия внесения изменений в какую либо версию.
Принципы SCM
Понимание сути SCM
Любой сотрудник организации, которая пытается ввести у себя систему контроля продукта, должен прежде всего осознать, что именно применение SCM является залогом успеха. Осмысление важности SCM происходит через процесс обучения. Администрация и менеджеры компании должны четко понимать как преимущества, так и затраты, связанные с внедрением SCM, и оказывать необходимую поддержку в реализации системы. Разработчики ПО должны знать основы SCM, поскольку они используют этот инструмент при разработке своих программных продуктов. Отсутствие понимания сути SCM или частичное выполнение обходными путями или с «черного входа» приведет к краху системы SCM.
Планы и политики SCM
Разработка политики SCM и последующих планов по каждому разрабатываемому продукту имеет решающее значение для успешной реализации SCM. Введение SCM в какой-либо организации, как и любой другой проект, требует затрат времени и денег. Организации необходимо придерживаться графика выполнения работ и поставки конкретных сборочных узлов. В стратегии в сжатой форме определены ожидаемые результаты, которые надеется получить организация. Эта стратегия должна привести к ожидаемым преимуществам и предоставить метод для измерения эффективности этих преимуществ.
Процессы SCM
Для того чтобы все пользователи могли ознакомиться с конкретными процессами SCM, их внимательно документируют. Необязательно использовать все процессы SCM в организации или в разработке продукта. Процессы, которые применяет организация, должны быть систематизированы в «доходчивой форме». Кроме того, эта «форма» должна отражать способ выполнения процесса.
Метрические показатели
Организации должны иметь показатели (метрические показатели), которые отражают, насколько ее деятельность соответствует выбранной политике и планам по разработке продукта. Они показывают эффективность, благодаря которой организация сможет получить максимальную пользу от внедрения SCM.
Инструменты для SCM
Инструментальные средства, используемые для реализации SCM, — это предпоследний элемент в списке. Для большинства менеджеров он часто является первым, а не пятым элементом, так как многие организации просто покупают инструментальное средство и ожидают чуда. Фактически бессмысленно подбирать инструментальные средства для их использования в SCM, не выполнив всю предыдущую работу. Применять инструментальные средства без обучения, стратегии или системы показателей — это все равно, что автоматизировать хаос. У вас просто будет автоматизированный способ получить плохой продукт быстрее.
Элементы конфигурации SCM
Элементы конфигурации — это те «вещи», которые представляют внутренние и внешние сборочные узлы проекта. Они являются окончательным результатом всей работы, проделанной с целью реализации SCM в масштабах какой-либо организации. Распространенная ошибка управления состоит в игнорировании требования SCM о соответствующих инвестициях в обучение. Процесс SCM и инструментальные средства, используемые при его реализации, являются достаточно сложными и требуют обязательного обучения. Для эффективного выполнения SCM необходим план перехода. Внедрение управления конфигурацией — это, по сути, проект, и как любой проект он требует план по его выполнению в контексте данной организации. Для того чтобы система SCM была эффективной и выгодной, необходимо разработать планы по повышению качества изделия и снижению времени разработки.
Вообще говоря, SCM — это идентификационная схема для компонентов ПО системы. Она контролирует изменения в конфигурации и поддерживает целостность и трассировку конфигурации. ПО в этом контексте относится ко всем поставляемым продуктам: документации, тестовым сценариям, файлам тестовых данных, коду и т.д. Контроль изменений — это менеджмент изменений, как одно из частей процесса SCM. Контроль версий — это менеджмент полученных версий программного продукта как частей процесса SCM. Контроль выпусков — это преобразование элементов конфигурации в завершенный программный продукт.
Элемент конфигурации (Configuration item, CI) — это самостоятельная часть разработки продукта, которая объединена с другими элементами конфигурации в версию.
Примеры элементов конфигурации ПО включают: проектные документы, инструкции и учебные пособия, статистические данные, отчеты по сбоям (выявленным неисправностям) программы, технические требования, исходный код и совокупность тестовых данных.
Основные требования для системы SCM
Идентификация, контроль, аудит и учет состояния являются базовыми требованиями для системы менеджмента конфигурации ПО. Эти требования необходимо выполнять независимо от степени автоматизации в пределах процесса SCM. Все четыре требования решаются с помощью инструментальных средств SCM, набора инструментальных средств или комбинации автоматизированных и ручных процедур.
Идентификация
Это обозначение каждой части ПО с целью ее идентификации в дальнейшем. Более того, могут существовать различные версии элементов ПО, которые постепенно совершенствуются, поэтому номер версии должен быть связан с этим элементом. Главная задача состоит в том, чтобы можно было идентифицировать любой или все артефакты, которые образуют окончательный элемент конфигурации.
Контроль
В контексте менеджмента конфигурации контроль означает анализ предложенных изменений в элементе конфигурации и в случае их принятия, т.е. введение их в конфигурацию ПО. Цель контроля состоит в том, чтобы принять обоснованное информированное решение и признать возможные последствия, связанные с изменением системы. Эти изменения могут оказать влияние на бюджет проекта, график его выполнения и вызвать изменения в других компонентах. Если о проблеме сообщают в конечном продукте, то разработчики ПО должны действовать быстро, чтобы оценить последствия — «устранение» ошибки для одной клиентской версии программного продукта может быть опасной для других. Контроль в системе SCM позволяет выявить каждую версию, в которой появляются недоработанные компоненты.
Аудит
Аудит в системе SCM означает, что утвержденные запрашиваемые изменения действительно выполнены. Аудит позволяет менеджерам определить, действительно ли эволюция ПО происходит логично и в соответствии с требованиями для данного ПО. Система SCM должна документировать все
изменения, версии и информацию о времени выпуска продукта для всех компонентов каждого элемента конфигурации. При наличии такой документации ревизия становится простой аналитической задачей.
Учет статуса
Отчеты и документация, выполненные функцией учета состояния, являются контролируемыми элементами (вводимыми данными). Все утвержденные части конфигурации ПО должны быть объяснены и соответствующий перечень должен отражать переход от части n элементов конфигурации к n + 1. Этот учет предоставляет статистическую информацию (предысторию), которая позволяет определить, когда и какие изменения происходили в программном проекте, и таким образом осуществить ревизию требований SCM. Учет статуса дает возможность охватить весь спектр информации в отношении деятельности организации на протяжении всего жизненного цикла продукта при его разработке и эксплуатации. Для менеджера программного проекта учет состояния чрезвычайно важен при оценке новых систем, базирующихся на статистических данных. Систему SCM можно использовать как один из ключевых компонентов системы оценки проекта.
Планирование и организация SCM
При планировании SCM в вашей организации по разработке продукта вы вначале должны определить проблемы, которые вызывают необходимость управления конфигурацией.
Проблемы: связанные с SCM
Групповой синдром разработчика
Если для разработки проекта требуется более одного разработчика, то возникает проблема группы людей, работающих над одной базой продукта. В данном случае базой может быть план проведения испытаний, требования к спецификации или коду. Усилия тратятся впустую, несколько человек работают над одним и тем же файлом, а затем его сохраняют. Без контроля SCM сохраняются только изменения, записанные последним, кто работает над этим файлом; все остальные изменения — теряются. Самое простое решение проблемы лежит в блокировании файла на время работы с ним одним из сотрудников, чтобы предотвратить одновременную работу над ним нескольких человек.
Множественность версий
Совершенствование базового продукта приводит к выпуску дополнительных версий с самыми последними изменениями. Несмотря на наличие последней модернизированной версии программного продукта, часть пользователей продолжает работать с более ранней версией. Продукт SCM позволяет контролировать все версии. Если в программе обнаружены ошибки, то изменения необходимо сделать во всех версиях. Как только в продукте появляются новые свойства, они должны быть доступны для всех пользователей независимо от времени выпуска версии продукта.
Семейство программных продуктов
Поскольку программные продукты созданы для того, чтобы предлагать аналогичные функции с помощью неоднородных платформ аппаратного обеспечения, необходимо управлять как программным продуктом вообще, так и ПО на базе определенной аппаратной платформы. Если программный продукт работает с четырьмя версиями Windows, тремя версиями Unix, Red Hat Linux и FreeBSD, то руководство для пользователя должно быть аналогичным. Но для этих девяти платформ необходимы разные процессы установки ПО. Без применения SCM придётся написать девять отдельных руководств пользователя по данному программному продукту. При наличии SCM достаточно будет одного комплекта документации, куда будут входить все девять версий, которые будут отличаться лишь процедурой инсталляции программного продукта.
Изменение требований
Независимо от этапа жизненного цикла системы, система/ПО будет изменяться, а желание изменить её будет постоянно возникать на всем протяжении жизненного цикла продукта. Борьба с такими изменениями представляет собой сложную управленческую проблему. Наличие SCM облегчает управление такими изменениями требований к продукту. SCM позволяет легко идентифицировать наборы функциональных возможностей, которые объединяют требования, которым отвечает версия продукта. Этот набор функциональных возможностей отслеживается от разработки до поставки продукта.
Изменение графика работ
Поскольку технические требования изменяются, должен изменяться и график их выполнения. Составление календарного плана с учетом набора функциональных возможностей для версии позволяет менеджерам проектов более точно распределять силы, необходимые для выпуска следующей версии программного продукта. Наличие SCM дает возможность на основе статистических данных сравнивать эффективность работы при подготовке новых версий. Статистические данные помогают оценить развитие событий типа «а что, если», которые происходят в результате успешного внедрения программного продукта среди новых потребителей или предоставлении выполненных по заказу продуктов другим клиентам.
Изменения ПО
Ни один разработчик не позволяет себе, однажды написав программу, полностью о ней забыть. Разрабатываемое ПО изменяется не только при изменении технических требований и календарных планов, но и в ответ на изменения в других элементах. ПО не является догмой. В этом и заключается его ценность. Программный продукт можно изменять, поэтому его и изменяют. Системы SCM отслеживают эти изменения, а если внесено неверное изменение, то всегда можно посмотреть предыдущую рабочую версию. Только одна эта функция SCM экономит огромное количество времени, поскольку разработчики проверяют конкретные задачи, которые не работают в среде программного продукта, и могут быстро перейти к рабочей версии.
Изменения штата
Во всех организациях сотрудники продвигаются по служебной лестнице, переходят на другую работу или увольняются. Если это происходит в разгар работы по разработке ПО, то с уходом специалиста теряются не только технологические знания. Теряются также практические знания по разработке продуктов, на овладение которыми ушло много времени. Новые сотрудники, даже зная технологию, не смогут заниматься разработкой продукта без задокументированного процесса SCM. Таким образом, SCM является точкой отсчета и базой данных об истории разработки проекта. Благодаря SCM новый сотрудник может узнать, «как» идет процесс разработки в организации и «что нового» в проекте на конкретную дату.
Service Oriented Architecture. Основные положения. Понятие Сервиса
Введение
Напомним определение программной архитектуры, которое будет использовано в этой главе.
Программная архитектура – это набор утверждений, которые описывают компоненты ПО и относит функциональность систему к тому или иному компоненту. Она описывает техническую структуру, ограничения и характеристики компонент и интерфейсов между ними. Архитектура это некий набросок верхнего уровня или неявный план, согласно которому строится система.
Сервис-ориентированная архитектура основывается на 4 абстракциях [26]:
Несмотря на то что application frontend часто выступает в роли основного «владельца» бизнес процесса, именно сервис предоставляет ту бизнес функциональность, которую application frontend и другие сервисы могут использовать. Сервис состоит из реализации которая обеспечивает бизнес логику и данные; контракта на обслуживание, который определяет функциональность, использование и ограничения для клиентов сервиса; кроме того, сервис предоставляет интерфейс который экспортирует функциональность для использования вне сервиса. Репозиторий сервисов хранит индивидуальные контракты сервисов всей архитектуры SOA. Шина сервисов (service bus) обеспечивает взаимодействие сервисов и прикладных интерфейсов.
Ниже схематично представлен состав основных абстракций SOA.
Сервисы – это, как правило крупные, части функциональности системы, которые не имеют встроенных прямых вызовов между собой. Т.е. относительно независимы по реализации. Вместо прямых вызовов друг-друга, они общаются с помощью специально утверждённых протоколов.
Сервис-ориентированная архитектура – это архитектура, основывающаяся на четырёх основных абстракциях (application frontend, service, service repository и service bus). Сервис состоит из контракта, одного или нескольких интерфейсов и реализации.
Оркестратция (планирование, организация) – деятельность, выполняемая как экспертом в бизнес области, так и специальным ПО, направленная на выстраивание цепочки и условия вызова сервисов.
Сервис-ориентированная архитектура фокусируется на понятии бизнес инфраструктуры. Здесь, под понятием сервис, в первую очередь подразумевается бизнес сервис, такой как, например, резервирование авиабилета. Такой сервис предоставляет бизнес операции, такие как: получить резервирование, отменить резервирование или получить профиль заказчика. В противоположность бизнес сервисам, технические сервисы, такие как хранение данных (persistency), управление транзакциями, предоставляют такие операции как: начать транзакцию, сохранить данные и т.п. И хотя технические операции несомненно являются очень важными, они имею мало отношения к бизнес функциям системы и поэтому имеет смысл исключать их из рассмотрения бизнес архитектуры системы. Вообще говоря SOA должна позволять отделить бизнес архитектуру системы от её технических деталей, тем самым оставляя свободу реализации того или иного сервиса.
Application frontend – это тот компонент SOA, который предоставляет функциональность конечным потребителям. Тем не менее, всегда следует иметь ввиду, что именно сервисы представляют струкруру и архитектуру SOA системы. Сервисы часто остаются неизменными на протяжении многих лет, в то время как application frontend и свяи между сервисами могут изменяться достаточно гибко и часто. Как следствие – время жизни application frontend значительно короче чем service’а.
Дата добавления: 2015-10-24; просмотров: 102 | Нарушение авторских прав
| <== предыдущая страница | | | следующая страница ==> |
| Введение в Rational Unified Process | | | Введение. Что такое Контейнер объектов и зачем он нужен |