MSF на Intuit.ru
Прошел курс "Технологии программирования на базе Microsoft Solutions Framework" на Intuit.ru и даже получил диплом набрав 87 баллов.
Данный курс читается в 4-ом семестре и опирается на прочитанные ранее общие курсы CS101 "Введение в методы программирования", CS102 "Методы объектно-ориентированного программирования", в рамках которых студенты знакомятся с фундаментальными понятиями, принципами и методами программирования, изучают основные алгоритмы, простейшие структуры данных, языки программирования Object Pascal и C/C++. В 3-ем семестре студенты изучают первую часть курса CS103 "Алгоритмы и структуры данных", выполняют лабораторные работы согласно учебному плану. Таким образом, полученных к 4-му семестру знаний и навыков достаточно для того, чтобы приступить к ознакомлению с технологиями коллективной разработки программ.
Конечно, уровень студента 2 курса все еще не позволяет овладеть этой темой полностью, поэтому учебный план предполагает изучение нескольких последовательно расположенных курсов, первым из которых, вводным, является данный курс - "Технологии программирования. Курс на базе Microsoft Solutions Framework (MSF)".
Курс так себе - можно почитать для общего развития. Курс расчитан на 2 курс института. Присутствуют примеры и презентации. Что-то подкачало описание выше - внутри курса исходники проект на Java.
Читал несколько лет назад редакцию 3.0 на русском. Автор курса пишет, что изменений в версии 4.0 много, но особо на них не останавливается. Основное различие это разделение на два типа процессов - легкий и тяжелый.
Вот бы кто сделал MSF в Eclipse EPF ..
********
Обширная фотогалерея современных офисов бизнес центров, банков представлена на сайте "Архитектурной студии Кузьмина" по адресу k-studio.ru. Спешите видеть, как обставляются самые роскошные офисы в мире.
Не знаете, что такое андроидный коллайдер? Исчерпывающий ответ найдется в блоге Ивана Победы!
Программная инженерия
Термин "программная инженерия - ПИ" (Software Engineering-SE) впервые прозвучал на научной конференции НАТО в 1968г. К этому моменту программное обеспечение (ПО) проникло во все сферы человеческой деятельности, а его разработка стала массовым занятием. Спрос на ПО постоянно увеличивается, сложность его растет, а ошибки не уменьшаются. Типовой программный проект разрабатывается, как правило, 1-2 года и его затраты составляют 39%. Готовый проект сопровождается примерно 6-7 лет и затраты на это составляют 61% от общей стоимости ПО. По разным причинам многие программные проекты являются убыточными.
К настоящему времени разработкой ПО занимается более 10 млн., а пользуются ими 100 млн. человек. Стабильные знания в этой области составляют 75% от тех знаний, которыми пользуются разработчики ПО в своей практической деятельности. Около 20 стандартов ISO регламентируют процессы управления проектированием, тестированием и оценкой качества ПО. Однако, как свидетельствует статистика, эффективность труда разработчиков колеблется в отношении 20:200 в зависимости от их квалификации.
Одним из путей повышения квалификации разработчиков ПО является систематизация накопленных в программной инженерии знаний и обучение этим знаниям разных специалистов. С этой целью мировая профессиональная общественность проводит широкие дискуссии в специальных журналах (IEEE Transaction on Software Engineering, Software Engineering Notes, Открытые системы и др.) и на международных конференциях по SE. Для объединения усилий международные профессиональные компьютерные объединения ACM и IEEE Computer Society создали специальный комитет (1999г.), который определил дефиницию программной инженерии и структуру знаний - ядро SWEBOK (Software Engineering Body of Knowledge).
Программная инженерия - зто отрасль компьютерной науки, которая изучает вопросы построения компьютерных программ, отражает закономерности развития в ней знаний, обобщает накопленный опыт в виде комплексов общих правил (дисциплины) регламентации инженерной деятельности разработчиков ПО. Основная цель ПИ - управление построением ПО, снижение в нем ошибок, повышение качества ПО и повышение производительности труда за счет готовых компонентов и систем. Парадигма ПИ содержит базовые концепции, ключевые понятия, жизненный цикл (ЖЦ), определяющие суть процесса построения ПО, элементы ПО (модули, объекты, компоненты, интерфейсы и др.), методы их построения и оценки.
Требования к ПО - определения
По Вигерсу и Лефингуэлу с Уидригом ...
Цели
Цель разработки ПО состоит в том, чтобы, уложившись в отведенное время и бюджет, разработать качественное программное обеспечение, удовлетворяющее реальные потребности пользователей.
Успех проекта ПО зависит от хорошо организованного управления требованиями.
Ошибки в требованиях - наиболее часто встречающийся тип ошибок при разработки систем, а их устранение наиболее дорогостоящим.
Использование нескольких ключевых приемов может значительно снизить вероятность ошибок в требованиях и, следовательно, повысить качество программного обеспечения.
"Недостаточное участие пользователей — общепризнанная основная причина провала проектов по разработке ПО (The Standish Group, 1995)."
"Нет ничего более важного для успеха проекта по разработке ПО, чем понимание того, что проблемы необходимо решать. Требования составляют фундамент успеха. Если команде разработчиков и клиентам не удастся достичь соглашения по поводу возможностей и характеристик продукта, то вероятнее всего вы получите такой результат, которого все мы хотели бы избежать."
"Многие разработчики не умеют спокойно и профессионально собирать требования пользователей к ПО. У клиентов зачастую не хватает терпения участвовать в разработке требований к ПО, или они норовят передать свои пожелания через совершенно неподходящих для этого дела людей."
"Отдельные участники проекта с большой неохотой возьмутся за применение новых способов формулирования требований. Некоторые люди откровенно неблагоразумны,..."
диалог Спакла и Марии
.."Ты не можешь винить меня за то, что я не умею читать мысли в твоей голове".
"Это как раз то, из-за чего я ненавижу компьютерные системы".
"Большинство людей при строительстве дома даже не интересуются подрядчиками, пока в полном объеме не обсудят свои потребности и желания и не уточнят все детали. Покупатели понимают, что внесение изменений влечет за собой изменение цены; им это не нравится, но они это понимают."
"Полный бред объявлять о готовности требований, если на самом деле у вас есть куча электронных писем, голосовых сообщений, записок, протоколов совещаний и неясных воспоминаний о беседах в коридоре."
"Большинству разработчиков знакомо чувство расстройства, возникающее, если их просят реализовать слишком неясные или неполные требования. Если они не могут получить необходимую информацию, они вынуждены ориентироваться на собственные предположения, которые не всегда верны. Потребуется много усилий, чтобы исправить ошибки в требованиях, работа над которыми уже завершена. Исследования показали, что в 100 раз дороже исправлять ошибки в требованиях, если на них указывает клиент, чем в процессе разработки этих требований (Boehm, 1981; Grady, 1999). Другие исследования свидетельствуют, что на исправление ошибки, выявленной на стадии работы над требованиями, тратится в среднем 30 минут, тогда как на исправление ошибки, выявленной в ходе тестирования системы, необходимо от 5 до 17 часов {Kelly, Sherif и Hops, 1992). Ясно, что любые усилия, затраченные на выявление ошибок в спецификации к требованиям, сэкономят реальные время и деньги."
"Наиболее хорошо себя зарекомендовавшая себя форма официальной оценки называется экспертизой (Gilb и Graham, 1993; Radice, 2002). Возможно, инспектирование документации требований - наиболее действенный из доступных приемов проверки качества ПО. Несколько компаний сэкономили ни много ни мало — целых 10 часов труда на каждый час, потраченный на инспектирование документации требований и других готовых к поставке продуктов (Grady и Van Slack, 1994). Инвестиции в проверки вернутся 1000% выгоды, если вы, конечно, не отнесетесь к ним небрежно."
"Аналитик должен изучить требования, оценить масштаб и составить представление о размере до того, как кто-нибудь приступит к расчетам или возьмет на себя определенные
обязательства."
"Ловушка: Не полагайте, что все лица, заинтересованные в вашем проекте, разделяют общее представление о том, что же такое требования. Задайте определения авансом, чтобы вы все изначально говорили на одном языке."
Карл Вигерс
"Строжайшее и единственное правило построения систем ПО - решить точно, что же строить. Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, с механизмами и с иными системами ПО. Никакая другая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа работы не исправляются так трудно."
Фред Брукс
Определения
* IEEE Standard Glossary of Software Engineering Terminology (1990) определяет требования как:
условия или возможности, необходимые пользователю для решения проблем или достижения целей;
условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
документированное представление условий или возможностей для пунктов 1 и 2.
бизнес-правило — это положение, определяющее или ограничивающее какие-либо стороны бизнеса; его назначение — защитить структуру бизнеса, контролировать или влиять на его операции.
на каждый химический контейнер нанесен уникальный штрих-код;
оплачивается доставка каждого заказа;
каждый элемент заказа содержит данные о химикате, его качестве, размере контейнера и числе контейнеров;
стоимость билетов не возвращается, если покупатель изменяет маршрут;
со стоимости доставки налог с продаж не берется.
ограничения - определяют операции, которые могут выполнить система и ее пользователи.
договор о займе человека младше 18 лет должен подписывать один из его родителей или законный опекун;
постоянный посетитель библиотеки может отложить для себя до 10 книг;
сотрудник может запросить вещество из списка химикатов первого уровня опасности, только если за последние 12 месяцев он прошел обучающий курс работы с опасными соединениями;
все программы должны соответствовать правительственным постановлениям, касающимся использования их людьми с ослабленным зрением;
в корреспонденции не может отображаться больше 4 цифр номера социального страхования гражданина;
экипажи коммерческих авиарейсов должны каждые 24 часа отдыхать не менее 8 часов.
Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга
Требования пользователей (user requirements) описывают цели и задачи, которые пользователям позволит решить система.
Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований
Бизнес-правила (business rules) включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Не являются требованиями к ПО, потому что они находятся снаружи границ любой системы ПО. Часто налагают ограничения, определяя, кто может выполнять конкретные use-case, или диктовать, какими функциями должна обладать система, подчиняющаяся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. можете отследить происхождение конкретных функциональных требований вплоть до соответствующих им бизнес-правил.
Спецификация содержит нефункциональные требования - описание целей и атрибутов качества. дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. Легкость и простота использования, легкость перемещения, целостность, эффективность и устойчивость к сбоям, взаимодействия системы с внешним миром, ограничения дизайна и реализации.
Спецификация требований не содержит деталей дизайна или реализации (кроме известных ограничений), данных о планировании проекта или сведений о тестировании (Letting well и Widrig, 2000). Удалите указанные элементы из требований, чтобы из этого документа было
абсолютно ясно, что надлежит построить команде разработчиков.
Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта.
Характеристика (feature) — это набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют
бизнес-цели. В области коммерческого ПО характеристика представляет собой узнаваемую всеми заинтересованными лицами группу требований, которые важны при принятии решения о покупке - элемент маркированного списка в описании продукта. Характеристики продукта, которые перечисляет клиент, не эквивалентны тем, что входят в список необходимых для решения задач пользователей. В качестве примеров характеристик продуктов можно привести избранные страницы или закладки Web-браузера, контроль за орфографией, запись макрокоманды, он-лайновое обновление или изменение налогового кодекса, ускоренный набор телефонного номера, автоматическое определение вируса.
Характеристики отдельных положений спецификации требований
Полнота. Каждое требование должно полно описывать функциональность, которую следует реализовать в продукте. Описание должно содержать всю информацию, необходимую для разработчиков, чтобы тем удалось создать этот фрагмент функциональности. Восполните все пробелы в каждом фрагменте требований, прежде чем приступать к конструированию этой функции.
Корректность. Каждое требование должно точно описывать желаемую функциональность. Для соблюдения корректности необходима связь с источниками требований
Осуществимость. Необходима возможность реализовать каждое требование при известных условиях и ограничениях системы и операционной среды.
Необходимость. Каждое требование должно отражать возможность, которая действительно необходима пользователям или которая нужна для соответствия внешним
системным требованиям или стандартам. Кроме того, оно должно исходить от лица, которое имеет полномочия на запись положения. Отследите каждое требование вплоть до стадии сбора мнений пользователей, когда выявлялись варианты использования, бизнес-правила или другие источники.
Назначение приоритетов. Назначьте приоритеты каждому функциональному требованию, характеристике или варианту использования, чтобы определить, что необходимо для каждой версии продукта. Если все положения одинаково важны, менеджеру проекта будет трудно справиться с уменьшением бюджета, нарушением сроков, потерей персонала или добавлением новых требований в процессе разработки.
Недвусмысленность. Все читатели требований должны интерпретировать их одинаково, но естественный язык зачастую грешит многозначностью. Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям. «Ясность»— цель качества требований, связанная с точностью: читатели должны четко понимать каждое положение. Занесите все специальные и запутанные термины в словарь.
Проверяемость. Попробуйте разработать несколько тестов, чтобы установить, действительно ли в продукте реализовано каждое требование. Если требование не проверяется, вопрос его корректной реализации становится предметом заключения, а не целью анализа. Неполные, несогласованные, невыполнимые или двусмысленные требования также не проверяются (Drabick 1999).
Взаимосвязь с другими задачами
Требования составляют основу любого хорошо организованного проекта по разработке ПО, поддерживая технические и организационные задачи. Изменения способов разработки и управления требованиями повлияют на эти задачи, и наоборот. Связи с другими задачами проекта:
Планирование проекта. Требования служат основой для процесса планирования проекта. Те, кто отвечает за планирование, выбирают подходящий жизненный цикл разработки ПО и разрабатывают ресурсные сметы и график работы на основе требований. Эта процедура может выявить невозможность реализации всего желаемого набора возможностей за отведенное время при выделенных ресурсах, В результате планирования иногда становится ясно, что следует сузить проект или выбрать инкрементальную модель либо модель постадийной реализации необходимой функциональности.
Трассирование и контроль проекта. Трассирование подразумевает мониторинг статуса каждого требования, чтобы менеджеру проекта было ясно, действительно ли конструирование и проверка выполняются согласно принятому по плану. Если нет, он может потребовать сузить границы рассматриваемого объекта через процесс управления
изменениями.
Управление изменениями. После того как набор требований внесен в основную версию, все последующие изменения выполняются только через определенный процесс управления изменениями. Этот процесс помогает гарантировать, что:
все понимают эффект предлагаемого изменения;
уполномоченные сотрудники смогут обоснованно принимать решения об изменениях;
все люди, которых затронут изменения, осознают их;
ресурсы и обязательства выверены;
документация требований обновляется своевременно и точно.
Тестирование системы. Пользовательские и функциональные требования представляют собой важнейшие входные данные для тестирования системы. Если предполагаемое поведение ПО в различных условиях не определено четко, тестировщикам будет чрезвычайно трудно обнаружить дефекты и проверить, вся ли запланированная
функциональность реализована должным образом.
Процесс конструирования. Несмотря на то что работающая программа и есть конечный продукт проекта по разработке ПО, требования предоставляют основу для работы по конструированию и реализации и связывают воедино различные этапы разработки. Проверяйте построенные компоненты, чтобы удостовериться, что каждый из них точно соответствует требованиям. Тестирование блоков позволяет проверить, удовлетворяет ли их код спецификациям и соответствующим требованиям. Трассирование требований позволяет задокументировать, какие элементы конструкции и кода ПО были получены на основе каждого требования.
Разработка пользовательской документации. Требования к продукту содержат данные для процесса разработки пользовательской документации, так что плохо
сформулированные или запаздывающие требования порождают проблемы в документации.
***
"Я работаю в группе тестирования. У нас нет написанных требований, поэтому мы должны протестировать систему на предмет того, что она с нашей точки зрения должна делать. Иногда мы ошибаемся, тогда мы узнаем у разработчиков, каковы функции системы, и тестируем ее снова». Тестирование того, что разработчики создали, - не то же самое, что тестирование того, что они должны были создать. Требования - это конечный документ для системных и пользовательских проверочных испытаний. Если требования к системе сформулированы плохо, то тестеры обнаружат множество предположений, реализованных разработчиками. Некоторые из них отражают соответствующие решения разработчиков, другие же отшлифованы или неверно истолкованы. Аналитик должен включить предположения и их источники в спецификацию требований к ПО, чтобы провести будущее повторное тестирование более эффективно."
************
Своевременное страхование имущества - это лучший способ оградить нажитое тяжелым трудом от кражи либо пожара.
Требования к ПО - аналитик
по Вигерсу
Аналитик требований — это основное лицо, отвечающее за сбор, анализ, документирование и проверку требование к проекту. Это основной коммуникативный канал между группой клиентов и командой разработчиков.
Определить бизнес-требования. «Зачем мы начинаем этот проект?»
Определить заинтересованных лиц и классы пользователей. Выявить важные классы пользователей и прочих заинтересованных в продукте лиц. Совместно с заказчиками следует выбрать соответствующих представителей каждого класса, заручиться их поддержкой и согласовать обязанности.
Выявить требования. Aналитик помогает пользователям четко обрисовать функции системы,необходимые им для достижения бизнес-целей. Для этого есть множество способов сбора информации:
интервью;
семинары;
анализ документов;
опросы;
посещение рабочих мест клиентов;
анализ бизнес-процессов;
анализ документооборота и задач;
списки событий;
анализ конкурирующих продуктов;
исследование существующих систем;
ретроспективы развития предыдущего проекта.
Анализировать требования. Ищите производные требования, логически проистекающие из запросов клиентов, а также невысказанные ожидания, которые, как считают клиенты, и так будут реализованы. Сразу же проясните неясные и неубедительные слова, порождающее двусмысленность. Выявите конфликтующие требования и области, требующие подробной детализации. Определите функциональные требования с такой степенью подробности, которая необходима разработчикам.
Создавать спецификации с требованиями. В результате формулировки требований формируется коллективный взгляд на систему. Аналитик отвечает за хорошую организацию спецификаций, в которых этот взгляд четко отражен. В результате применения стандартных шаблонов для вариантов использования продукта и спецификации требований к ПО создание документации ускоряется, поскольку у аналитика перед глазами постоянно находится перечень тем, которые нужно обсудить с представителями пользователей.
Моделировать требования. Аналитик должен определить, полезно ли представлять требования нетекстовыми средствами, например с помощью разнообразных моделей графического анализа, таблиц, математических уравнений, раскадровок и прототипов. Модели анализа отражают информацию на более высоком уровне абстракции, чем подробный текст. Для максимальной прозрачности и эффективного общения рисуйте модели анализа, используя правила стандартного языка моделирования.
Управлять проверкой требований. Аналитик должен гарантировать, что формулировки требований отвечают всем необходимым характеристикам, и что система на основе этих требований устроит пользователей. Аналитики участвуют в обзорах документов с требованиями. Им также следует изучить архитектуру, код и варианты тестирования, спроектированные на основе спецификаций требований, и убедиться, что требования интерпретированы правильно.
Обеспечить расстановку приоритетов требований. Аналитик обеспечивает общение и взаимодействие различных классов пользователей с разработчиками, что позволяет расставить приоритеты.
Управлять требованиями. Аналитик требований вовлечен во все этапы разработки ПО, его задача — помочь создать, обсудить и осуществить план управления требованиями к проекту. Создав документацию, аналитик управляет требованиями и проверяет, как они реализуются в продукте. Управление требованиями подразумевает контроль за состоянием отдельных функциональных требований по мере степени готовности продукта.
Необходимые навыки
умения слушать, задавать вопросы, навыки анализа, создавать комфортные условия общения, наблюдательность, межличностное общение
Навыки написания документации. Основной итог процесса создания требований — письменная спецификация с информацией для клиентов, отдела маркетинга и технического персонала. Аналитик должен отлично владеть языком и ясно выражать сложные идеи.
Организационные навыки. Аналитик имеет дело с большим объемом беспорядочной информации, собранной на первом этапе. Чтобы справиться с данными и выстроить согласованное целое, вам потребуются исключительные организационные навыки, а также терпение и упорство для вычленения основных идей из хаоса.
Навыки моделирования. Аналитик должен уметь работать с разнообразными средствами, начиная с древних блок-схем и структурированных моделей анализа ..
Творческий подход. Аналитик — не просто клерк, записывающий все высказывания клиентов. Лучшие аналитики изобретают требования (Robertson, 2002). Они предлагают инновационные функции продуктов, новые рыночные возможности и возможности для бизнеса и думают, как удивить и удовлетворить своих клиентов.
Инвестиции в моделирование
Давно хотел решить вопрос с моделированием. Главная предпосылка - моделирование все равно должно быть. Если проект это не три формы и две таблицы - нужно моделировать. Приверженцы гибкого моделирования говорят: "Моделировать чтобы понять." Мне же хочется большего. Хочется на основе моделей получить код. И современные средства моделирования неплохо с этим справляются. Посмотрите на Together в сочетании с C++, C# и Java!
Т.е. можно добавить к "моделируйте чтобы понять", если это возможно "моделируйте, что построить код!". Вспоминаю как я пытался избежать построения моделей в ERWin в институте. Мне казалось, что это рисование ничего больше рисунка не принесет. Хорошо, что преподаватель вовремя объяснил, что это не только рисование а еще и гибко настраиваемая генерация DDL кода. И плюс к тому же обратное проектирование из DDL-скриптов и работающих БД, практически всех популярных производителей (Oracle, IBM, MS). С тех пор с ERWin я не расстаюсь. Даже когда предметная область ясна и не нужно "моделировать чтобы понять". Я прежде всего моделирую чтобы построить.
UML не был слишком востребован в моей практике. Наверное из-за специфики приложений, ориентированных на ввод данных, где 80% приложения это получение списка и простые операции вставки, редактирования и удаления.
К тому же для Delphi до некторого времени не поддерживалось ни прямое ни обратное проектирование. Существовал для Rational Rose RoseDelphiLink, но ожидаемого успеха он не приносил. Вообще во времена 2000-2001 Rose был довольно бедный на предмет генерации - не понимал реализацию - только заголовки методов, и можно было абсолютно чесно бояться что что-то испортится в процессе синхронизации. Кстати как там сейчас обстоят дела не знаю, надеюсь IBM исправила этот недостаток, по крайней мере для Java
Программы моделирования изменились с появлением Together с философией, что это не просто модели - модели и код это лишь разные представление одного и того же. Т.е. можно смотреть на код, можно на модель. Когда вы будете изменять код - автоматически будет изменяться модель, а когда менять модель - будет изменяться и код. И все это на довольно серьезном уровне даже диаграмм взаимодействия, где с выбранной вами степенью детализации прорисованы циклы и операторы (и все это можно двигать!)
Многие люди хотят облегчить себе жизнь при помощи моделирования. Особенно, когда моделирование неотъемлемая часть процесса разработки. В пользе моделировании СУБД я уверен на все 100%. Если вы еще не делаете этого настоятельно рекомендую - переход от модели к реализации с минимальными усилиями - моделирование окупается на все 100%.
Вообще OLTP приложения довольно просты, и можно пойти дальше. Используя модель данных (или физическую реализацию объектов СУБД) можно даже попытаться автоматически построить большую часть приложения, работающего с ней. Например предварительные сиквелы для всех объектов, формы списков и формы ввода данных ..
Кто начал с объектов и UML моделирования тоже может получить огромные выгоды прямо сейчас. Вопрос до конца пока не исследован мной, но кое что успел посмотреть.
Delphi и MDA for Net мало чего могу сказать и возможно мои знания уже не отвечают действительности - не исследовал должным образом - просто это цельная технология со своими плюсами и должно быть свойственными ограничениями. Стратегии хранения объектов в БД поддерживаются различные, автоформы есть, визуальное связывание есть. Есть также поддержка OCL и состояний. Поддержка унаследованных реляционных БД. Пугает, как обычно для объектных реализаций БД, способ управления жизнью объектов, хранение и оперативная память, и главное что делать при модификации объектной модели - как построить например обновления схемы СУБД без потери данных.
Привлекательно смотрится Hibernate с реализациями для двух самых популярных платформ Java и .Net. Хочется отметить что Hibernate меня например пугает меньше чем MDA - вы остаетесь в привычном объектом мире и если вам нужно постоянное хранение объектов используется ORM Hibernate - просто прячется слой хранения.
- Моделируем предметную область и получаем модель на языке программирования.
- Автоматически строим по объектной модели схему СУБД
либо
- по готовой схеме СУБД строим объектную модель, что тоже довольно неплхо смотрится для поддержки унаследованных БД
- по мере развития приложения можно повторять генерацию, а можно изменять карты отображения объектов СУБД в объекты языка программирования.
Т.е. вам не нужно отвлекаться на слой хранения даных - эти штуки вас от него абстрагируют - в идеале избавляют от целой трети работы (представление <-> логика <-> храниение)!
------------
Основное направление деятельности московской фирмы «Кумба» - строительство домов из бруса по типовому или индивидуальному проекту.
Двигатель программной революции. Scrum
Порадовал статьей osp.ru
Открытые системы #02/2007
Двигатель программной революции
Наталья Дубова
Scrum — простой процесс. Вначале так называемый «владелец продукта» — представитель заказчика или человек, который работает с заказчиком, — расставляет приоритеты в списке требований к программному продукту и передает этот список команде Scrum. Команда определяет, как много верхних элементов списка она в состоянии реализовать за 30 дней или меньше. Истоки Scrum лежат в принципах так называемого «экономного производства» (lean manufacturing), именно оттуда взят доказавший на практике свою эффективность принцип «вытягивания» требований. Для каждой очередной итерации команда «вытягивает» верхние элементы из списка приоритетов, разбивает полученный в результате список функций на список конкретных задач и начинает работать.
Scrum подразумевает ежедневные встречи команды, в которую входит семь плюс-минус два человека. На таких встречах каждый участник разработки отчитывается, что он сделал вчера, что должен сделать сегодня, какие проблемы у него возникли. В ходе общего сбора ищутся способы разрешения этих проблем. Как показывает опыт, такие ежедневные встречи способствуют продуктивности разработки.
Команда в Scrum работает на принципах самоорганизации: сама оценивает, какие функции из общего списка она в состоянии реализовать в тридцатидневный срок, и формирует соответствующий список работ, тем самым всегда стараясь выбрать наиболее быстрый способ построения приложения. Задача лидера команды — мастера Scrum — состоит в том, чтобы предоставить команде все возможности для реализации выбранных задач, но не диктовать, что должен делать каждый участник разработки.
С помощью специальных диаграмм мастер Scrum анализирует ход итерации, оценивает объем оставшихся задач и определяет текущий статус работ. Минимальная отчетность позволяет руководителю команды постоянно отслеживать, что происходит в проекте, обеспечивает полную прозрачность процесса... Оказалось, что 96% ИТ-директоров ничего не знают о промежуточном состоянии проекта, то есть фактически движутся вслепую. В Scrum руководитель постоянно наблюдает за состоянием проекта.
В XP Кент Бек фокусируется на инженерных практиках, показывая, что необходимо делать в процессе разработки, чтобы создать высококачественный программный продукт. В центре внимания Scrum — организация процесса командной разработки: как мотивировать членов команды на решение конкретных задач, как добиваться их выполнения. Scrum — это руководство командой, XP — инженерные практики. Эти методики взаимодополняют друг друга. Более того, Scrum не может обеспечить достаточно высокую продуктивность команды без надлежащих принципов программной инженерии, и поэтому мы рекомендуем обращаться к XP. С другой стороны, трудно применять XP в масштабных проектах, если нет эффективного метода управления командой, такого, как в Scrum. Поэтому оба эти метода нуждаются друг в друге: XP делает Scrum высокопроизводительным, а Scrum позволяет расширять масштабы XP-проектов.
--------
Если вы планируете ненадолго навестить столицу, но еще не решили где остановитесь – обратите внимание на аренду квартир в Москве посуточно. Привлекательные цены, возможность самостоятельного приготовления пищи и уютная домашняя обстановка – вот основные достоинства посуточной аренды жилплощади.
Структура интервью
Дождался реального проекта - оптимизация внутренних сервисов компании. Компания большая, более 10 структурных подразделений. Решили попробовать подумать про оптимизацию меж-структурного взаимодействия.
Сейчас обрабатываю информацию по структуре служб компании и предоставляемым сервисам. Информации мало - так общие фразы на верхнем уровне.
После того как соберу все имеющуюся электронную информацию, планирую подготовить небольшой опросник экспертам целевых служб.
Дале думаю разослать опросник и получить первое приближение потребностей без проведения общих совещаний (14 человек вряд ли будет эффективно, и возможно некоторые службы отсеются по каким-либо причинам).
До конца пока не решил с содержанием анкеты .. думаю будет содержать
- факты которые удалось выкопать из документов
- опрос услуг, которые предоставляет служба
- опрос услуг, в которых нуждается служба
После обработки полученной информации все это будет объединено в документе (видения ?) И уже можно строить планы на уточнение требований непосредственно с экспертами, в виде личных встреч и/или совещаний. Надеюсь после предварительной обработке размер группы экспертов удастся сократить до размера эффективного совещания.
Может посоветуете хороший шаблон анкеты?
...
Пока набрал из "Принципы работы с требованиями .. " Леффингуэлл, Уидриг. Но на мой взгляд это чересчур для пользователя. Хотя можно считать что пользователи компьютерно-грамотные.
----------
Добавить объявление о продаже программы совершенно бесплатно можно на сайте ktochto.ru.
В полной мере убедиться в правдивости утверждения о том, что красивые зубы - достоинство человека, вы можете в стоматологическом кресле. Своевременный уход за зубами избавит вас от необходимости долгой и затратной процедуры их восстановления.
SOA базовые определения
Шаблоны обмена сообщениями в архитектуре, ориентированной на сервисы. Часть 1.
Microsoft Architects Journal / Русская редакция
Соумен Чаттерджи, CG&Y (Индия)
SOA - совокупность компонентов, удовлетворяюищих бизнес-требованиям. В SOA входят компоненты, севрвисы и процессы. Компоненты - это двоичные модули, у которых имеются определенные интерфейсы (как правило только один), а севрис - это группа компонентов, выполняющих определенную функцию.
Сервис обычно реализуется как некая программная сущность, которую можно обнаружить и которая существует в виде одного экземпляра и взаимодействует с приложениями и другими сервисами, используя слабо-сопряженную (часто асинхронную) модель обмена данными, основанную на сообщениях.
Самая важная особенность SOA - отделение реализации сервиса от его интерфейса. Потребители воспринимают сервис просто как конечную точку взаимодействия, поддерживающую определенный формат запросов и контракт. Как сервис выполняет запросы потроебителей, не имеет значения; единственное обязательное требование состоит в том, что сервис должен возвращать данные потребителю, используя согласованный формат, определенный в контракте.
SOA-объекты - это различные объекты, которые образуют конфигурацию, реализующую парадигму "поиск, связывание и выполнение"
Потребитель сервиса - это приложение, сервис или любой другой программный модуль, которому нужен сервис. Он инициирует поиск сервиса в реестре сервисов, связывание с сервисом через транспорт и выполнение функции сервиса. Потребитель сервиса вызывает сервис, отправляя ему запрос, формат которого соответсвует контракту.
Провайдер сервиса - сущность, к которой обращаются через сеть и которая обрабатывает запросы потребителей. Провайдер сервиса публикует свой контракт в реестре сервисов, чтобы сделать контракт доступным потребителям сервисов.
Реестр сервисов - каталог, доступный через сеть и содержащий данные об имеющихся сервисах. Он получает контракты от провайдеров сервисов, хранит эти контракты и предоставляет их заинтересованным потребителям сервисов.
Контракт сервисов - это спецификация, описывающая, как потребитель сервиса будет взаимодействовать с провайдером сервиса. Контракт задает формат запросов и ответов. Контракт может требовать, чтобы выполнялась определенная пре- и постпроцессная обработка. Такая оброботка определяет состояние, в котором должен находится сервис, чтобы выполнить определенную функцию. Кроме того, контракт может задавать уровни качества обслуживания (QoS) и определять спецификации для нефункциональных аспектов сервиса.
Аренда сервиса. Срок аренды (время, в течении которого может сохранять состояние), передаваемый реестром сервисов потребителю сервисов, необходим для того, чтобы сервисы могли сохранять информацию о связывании потребителя и провайдера. Аренда обеспечивает слабое сопряжение потребителя и провайдера сервиса, на время, в течении которого провайдер и потребитель связаны между собой, ограничено. Без аренды потребитель мог бы постоянно оставаться связанным с сервисом и никогда не выполнять повторное связывание с контрактом сервиса.
Обнаружение и динамическое связывание: обмен сообщениями в SOA.
Потребитель запрашивает данные о сервисе из реестра, и реестр сервисов возвращает список всех провайдеров, которые поддерживают запрашиваемый сервис. Потребитель выбирает из списка провайдер, взаимодействие с которым наиболее эффективно, и связывается с ним, используя указатель из записи реестра сервисов.
Потребитель форматирует сообщение запроса в соответствии со спецификацией контракта и связывает сообщение с коммуникационным каналом, поддерживаемым сервисом. Провайдер запускает сервис и возвращает сообщение, соответствующее определению сообщения в контракте сервиса.
Единственной зависимостью между провайдером и потребителем является контракт, который предоставляет третий участник взаимодействия - реестр сервисов. Эта зависимость возникает во время выполнения, а не на этапе компиляции. Потребитель получает и использует всю необходимую информацию о сервисе в период выполнения. Интерфейсы сервиса обнаруживаются динамически, сообщения конструируются тоже динамически.
Потребитель сервиса не знает формат сообщения запроса или сообщения ответа и местонахождение сервиса до тех пор, пока не возникнет необходимость в сервисе
Возможность преобразования сообщений позволяет сделать приложение более независимыми друг от друга. Обмен сообщениями лежит в основе SOA; SOA не может существовать без обмена сообщениями.
Особенности при интеграции
EAI требует, чтобы вы заранее представляли, какие функции поддерживает каждое приложение. В SOA каждое прилолжение рассматривается как провайдер сервиса и обеспечивается динамическое обнаружение сервисов с помошью общего каталога сервисов - UDDI.
----------
Электроинструмент компании Makita всемирно известен своей феноменальной надежностью и продуманной эргономикой. Приобрести различные инструменты японской марки вы можете на строительном ресурсе Vseinstrumenti.ru.
Eclipse Process Framework (EPF) 1.2.0
Вчера вечером наступил день релизов. Как уже говорил первым был AllFusion ERWin DataModeler 7.2, вторым был OpenProj - мощный OpenSource инструмент аналог MS Projects, и третий собственно и тема этого поста.
Eclipse Process Framework (EPF) - это инструментальная платформа управления процессами и концептуальный фреймворк для создания, адаптации, развертывания разработанных процессов. При создании продукта разработчики руководствовались такими главными предпосылками.
Разработчики должны понимать методы и ключевый практики разработки ПО. Им должны быть хорошо знакомы базовые задачи разработки - извлечение и управление требованиями, анализ и проектирование, реализация дизайна, реализация тестовых случаев. Новых разработчиков нужно знакомить с применяемыми практиками.
Команде разработки нужно определить как применять эти методы и лучшие практики на протяжении жизненного цикла проекта. Они должны выбрать или определить процесс разработки.
Команде разработки нужен простой централизованный доступ к информации - поддерживаемая база практик и процессов. Обычно процессы не документированы полностью, или представлены в разных местах и различных форматах. Отмечается сложность интеграции в процесс разработки других практики и процессов в проприетарных форматах (книги, статьи)
Итак продукт
Предоставляет всем участникам разработки общую базу знаний - интеллектуальный капитал для просмотра, управления и развертывания. Контент управляемый в EPF может быть опубликован на веб сервере для распределенного использования.
Предоставляет каталог готовый процессов для типичных проектных ситуаций, которые могут быть адаптированы для индивидуальных целей. Он также предоставляет стандартные блоки построения процесса, предоставляющие лучше практики для специфических дисциплин, технологий, или стилей разработки.
Два основные концепции - это содержимое метода (Method Content) и процесс (Process). Эти две концепции прекрасно иллюстрирует знакомая картинка RUP, где по вертикали идут методы (method content: Bisnes Modeling, Requirements, Analysis & Design, Deployment, Management, configuration, Environment) а по горизонтали процессы - фазы и итерации.
Т.е. Method Content описывает как это может быть сделано, какие требуются навыки, пошаговое описание того, как добиться требуемых показателей. Эти методы не зависят от жизненного цикла. Method Content базируется на ролях, необходимых навыков и ответственности за рабочие продукты. Рабочие продукты производятся задачами которые выполняют роли, и имеют рабочие продукты как входы и выходы.
Процесс описывает сам жизненный цикл разработки и определяет последовательность осуществления выполнения работы ролями, и то как производятся и эволюционируют во времени рабочие продукты.
Хранения и структурирование контента определяется схемой, это развитие SPEM 1.1 OMG спецификации, ссылающейся на Unified Method Architecture (UMA). Такая организация контента не ограничивается производством ПО и пригодна в других инженерных дисциплинах.
Коммерческая версия IBM Rational Method Composer предоставляет лишь дополнительные материалы в основном по RUP domain-specific областям.
Готовые процессы
В стандартной поставке идет OpenUP и OpenUP/DSDM. Дополнительно предлагаются для загрузки процессы для XP и Scrum. Кроме самих библиотек можно загрузить и уже готовые для публикации версии всех этих процессов.
З.Ы.
Что мне понравилось, что для процессов есть шаблоны документов и примеры (.doc) и ко многим артефактам добавлены чек-листы. Дополнительно к публикации процесса, его можно экспортировать в MS Project (с файлами которого прекрасно справляется OpenProj).
В общем приятный инструмент, такая схема представления знаний выглядит по лучше SADT диаграммы 
Сбылись бы еще идиотские мечты, что кто-нибудь это переведет на русский язык Такой вопрос поднимался на uml2.ru, но особого движения что-то не наблюдалось. Интересно есть ли русские публикации по OpenUP и OpenUP/DSDM...
А кто и каким образом организовывает свои базы знаний по разработке?
Эпоха систем, терпимых к изменениям
Такая обзорная себе статья в osp.ru. Выдрал абзац на память
... Как ни странно это звучит, но именно процветание города могло, в конце концов, стать одной из причин его гибели.
Наиболее удачные программные системы часто повторяют судьбу процветавших античных городов. Разработчики проектируют программные системы с учетом потребностей и ограничений, накладываемых внешними факторами, которые со временем меняются. Эти системы могут прекрасно соответствовать имеющимся на данный момент целям, рынку или направлению бизнеса и быть популярными у пользователей. Но по мере роста числа пользователей системы, растет и спрос на нее. Этот спрос может негативно повлиять на производительность системы, если будет превышен предполагаемый ее создателями объем ресурсов. Спрос может инициировать появление возможностей, не поддерживаемых в исходной архитектуре программной системы. В таких случаях возникает необходимость изменить программное обеспечение. В конце концов, разработчики решают удовлетворить эти требования, опираясь на несовместимые ограничения по ресурсам. Как и строительство зданий за пределами городских стен, это рискованное решение, способное поставить систему под угрозу. С каждым следующим разом менять программное обеспечение становится все сложнее, и система теряет стабильность. Как ни парадоксально, именно успех программной системы способен привести к ее краху.
Разработчики программного обеспечения сталкиваются с ситуацией, аналогичной той, в которой оказывались их предки, строившие города, но теперь есть специалисты, способные помочь в создании и развитии систем, быстро и эффективно реагирующих на меняющуюся среду.
Дальше этого абзаца к сожалению идет информация мало пригодная для практического использования. Видно сказывается образование автора (доцент факультета информатики технического университета Вирджинии) ... статья то опубликована в IEEE Computer, June 2007
И опять хочется привести в пример такое ПО как СУБД, которое мало изменилось за последнее десятилетие. И особых причин и направлений не видно и до сих пор. А то что системы нужно строит как-нибудь по другому это понятно.
Не знаю может уже постил что-то подобное ... В общем утопия - современная система как набор интегрированных систем, каждая из которых развивается сама в себе, снижая общее влияние сложности на интегрированную систему. Таки общие подсистемы (полноценные системы, но в общем контексте выглядят как подсистемы) как:
BPMS - хранилище бизнес-процессов компании (включая взаимодействие с внешними системами
BRMS - хранилище бизнес-правил компании (скидки клиентов, точки принятия решений, ...)
UIMS (GUI management system) - хранилище интерфейсов пользователя, организованное в виде системы (стандартные - пользователи, права доступа)
И на каком-то техническом уровне дополнительно идет СУБД и система отчетов.