Archive for June, 2008

ProductSearch #1 Разработка требований. Бизнес-требования

Posted in Development, Product Search on June 26th, 2008 by Yaroslav Vorozhko – 2 Comments

Продолжаем разрабатывать ProductSearch. Прежде чем читать дальше, советую ознакомиться с первой статьей про ProductSearch, где я описал цели и общий план развития проекта.

В этой статья я буду вести речь про требования к ПО – кратко, что такое требования и какие бизнес-требования я определил для ProductSearch. 

Определение термина "требования к ПО", Карл Вигерс определил как:

Требования к ПО состоят из трех уровней – бизнес требования, требования пользователей и функциональные требования. Вдобавок каждая система имеет свои нефункциональные требования.

Следующий рисунок демонстрирует способ представления этих требований:

Виегерс Требования

В первую очередь надо разработать бизнес-требования.
Что такое бизнес-требования:

Бизнес-требования (business requirements) содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью.

read more »

ProductSearch #0 Создание проекта

Posted in Development, Product Search on June 24th, 2008 by Yaroslav Vorozhko – 4 Comments

С этого сообщения я начну разрабатывать небольшой проект под названием ProductSearch.

Описание проекта ProductSearch

Цель проекта ProductSearch – является создание единой базы продуктов различных поставщиков и поиск по базе данных.

ProductSearch будет состоять из трех частей:

  • Поиск по продуктам, результат поиска это ссылки на соответствующие категории продуктов
  • Категории продуктов
  • Страница описания продукта
  • Список предложений определенного продукта от поставщиков (магазинов)
  • Регулярное обновление базы продуктов предоставляемой поставщиками
  • Отчеты о поисковых результатах для поставщиков

Чем этот проект может быть лучше уже существующих? На такой вопрос сложно ответить, но основным преимуществом будет возможность – бесплатно добавлять продукты в базу.  Думаю основные преимущества проекта будут определены на этапе выработки требований.

Для поиска я планирую использовать Sphinx Search – мощный поисковый движок, который предоставляет массу возможностей для поиска, фильтрации, группировки и многие другие вкусности и полезности для организации поиска по базе данных.

Разработка будет итерационым процессом, поэтому первая версия будет включать в себя минимум требований достаточных для запуска системы.

Так как я планирую создать этот проект в образовательных целях, то вся работа над проектом будет публиковаться на этом блоге.

read more »

Основы #2 Выработка требований, предварительные условия ?

Posted in Development on June 22nd, 2008 by Yaroslav Vorozhko – 2 Comments

iceberg

Требования подробно описывают, что должна делать программная система, а их выработка – первый шаг к решению проблемы. Выработка требований также известна как "разработка требований", "анализ требований", "анализ", "определение требований", "спецификация", "функциональная спецификация".

Зачем нужны официальные требования?

Явные требования помогают гарантировать, что функциональность системы определяется пользователем, а не программистом. Если требования сформулированы явно, пользователь может проанализировать и утвердить их. Если явных требований нет, программисту обычно самому приходится вырабатывать их во время программирования. Явные требования позволяют не гадать, чего хочет пользователь.

Внимание к требованиям позволяет свести к минимуму изменения системы после начала разработки. Обнаружив при кодировании ошибку в коде, вы измените несколько строк, и работа продолжится. Если же во время кодирования вы найдете ошибку в требованиях, придется изменить проект программы, чтобы он соотвествовал измененным требованиям.

Адекватное определение требований – одно из важнейших условий успеха проекта, возможно, даже более важное, чем использование эффективных методов конструирования.

Миф о стабильных требованиях

Требования подобны воде. Опираться на них легче, если они заморожены.

При стабильных требованиях смена этапов разработки архитектуры, проектирования, кодирования и тестирования приложения происходит упорядоченно, предсказуемо и спокойно.

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

Что делать при изменении требований во время конструирования программы?

Следующие действия позволяют максимально легко перенести изменения требований во время конструирования.

Оцените качество требований Если требования недостаточно хороши, прекратите работу, вернитесь назад и исправьте их.

Убедитесь, что всем известна цена изменения требований Если руководители вашей организации не понимают важность предварительной выработки требований, укажите им, что изменения во время выработки требований обходятся гораздо дешевле, чем на более поздних этапах.

Задайте процедуру контроля изменений Если клиент никак не может успокоиться, подумайте об установлении стенда контроля изменений для рассмотрения вносимых предложений.

Используйте те подходы к разработке, которые адаптируются к изменениям Некоторые подходы к разработке ПО позволяют особенно легко реагировать на изменения требований. Подход эфолюционного прототипирования (evolution prototyping) помогает исследовать требования к системе до начала ее создания.

Оставте проект Если требования особенно неудачны или изменчивы и никакой из предыдущих советов не работает, завершите проект.

Помните о бизнес-модели проекта Многие проблемы с требованиями исчезают при воспоминании о коммерческих предпосылках проекта. Программисты, которые принимают во внимание коммерческие следствия своих решений, ценятся на вес золота.

Статья составлена из отрывков книги Стива Макконнелла, "Совершенный код".

Основы #1 Секрет Метафоры

Posted in Development on June 21st, 2008 by Yaroslav Vorozhko – 1 Comment

Теринология компьютерных наук – одна из самых красочных. Действительно, в какой еще области существуют стерильные комнаты с тщательно контролируемой температурой, заполненные вирусами, троянскими конями, червями, жучками и прочей живностью и нечестью?

Важность метафор

История науки полна открытий, сделанных благодаря метафорам. Так, химик Кенуле однажды во сне увидел змею, схватившую себя за хвост. Проснувшись, он понял, что свойства бензола объяснила бы молекулярная структура, имеющая похожую кольцевую форму.

Кинетическая теория газов была создана на основе модели "бильярдных шаров", согласно которой молекулы газа, подобно бильярдным шарам, имеют массу и совершают упругие соударения.

Аналогичным образом метафоры способствуют и лучшему пониманию вопросов разработки ПО.

Метафора, характеризующая разработку ПО, больше похожа на прожектор, чем на дорожную карту. Она не говорит, где найти ответ – она говорит, как его искать. Метафора – это скорее эвристический подход, а не алгоритм.

Как использовать метафоры, характеризующие разработку ПО? Используйте так, чтобы лучше разобраться в проблемах и процессах программирования, чтобы они помогали вам размышлять о выполняемых действиях и придумывать лучшие решения задач.

Использование метфор – дело тонкое. Чтобы метафора привела вас к ценным эвристическим догадкам, вы должны ее расширить. Но если ее расширить чересчур или в неверном направлении, она может ввести в заблуждение. Как и любой мощный инструмент, метафоры можно использовать неверным образом, однако благодаря своей мощи они могут стать ценным компонентом вашего интеллектуального инструментария.

Популярные метафоры, характеризующие разработку ПО

Коротко.

Литературная метафора: написание кода

Самая примитивная метафора, описывающая разработку ПО, берет начало в выражении "написание кода".

Сельскохозяйственная метафора: выращивание системы

Иногда хороший метод описывается плохой метафорой. В таких случаях попытайтесь сохранить метод и обнаружить лучшую метафору. В данном случае инкрементный подход полезен, но сельскохозяйственная метафора просто ужасна.

Метафора жемчужины: медленное приращение системы

При инкрементной разработке вы сначала создаете самую простую версию системы, которую можно было бы запустить. Создав скелет, вы начинаете понемногу наращивать плоть. Каждый из фиктивных классов вы заменяете реальным. Вы продолжаете добавлять нужные фрагменты, пока не получите полностью рабочую систему.

Раковина, формирующая жемчужину, – хороший вариант визуализации инкрементной разработки, или акреции.

Строительная метафора: построение ПО

Метафора "построение" ПО полезнее, чем метафоры "написания" или "выращивания" ПО, так как согласуется с идеей акреции ПО и предоставляет более детальное руководство. Построение ПО подразумевает наличие стадии планирования, подготовки и выполнения, тип и степень выраженности которых зависят от конкретного проекта.

Метафора построения-конструирования может быть расширина во многих других направлениях, именно поэтому она столь эффективна. Благодаря этой метафоре отрась разработки ПО обогатилась многими популярными терминами, такими как архитектура ПО, леса (scaffolding), конструирование и фундаментальные классы.

Статья составлена из отрывков книги Стива Макконнелла, "Совершенный код".

Введение в Мастера

Posted in Development on June 20th, 2008 by Yaroslav Vorozhko – Be the first to comment

Этим постом я начну новую серию статей по разработке программного обеспечения.

Основными тематиками будут:

  • Основы разработки ПО
  • Высококачественный код
  • Усовершенствование кода
  • Системные вопросы
  • Мастерство программирования

Вдохновение заниматься разработкой программного обеспечение, я получил от таких гуру программистов как: Гради Буч, Бъярн Страуструп, Мартин Фаулер, Стив Макконнелл и “Банде Четырех” – их труды невозможно переоценить, это лучший опыт и лучшие советы, которые можно почерпнуть из книг в области создания ПО.