Месяц: Апрель 2016

О взаимосвязи требований и решений

Walker Royce, http://walkerroyce.com/blog/:

Requirements is one of the most misused  words in our industry. Very few things are truly required. Most things are negotiable. Our understanding of the problem space evolves and changes as our understanding of the solution space and the constraint space (plans, economics, realities) evolves.

По-русски:

Требования — это одно из самых злоупотребляемых слов в нашей индустрии. Очень немногие вещи по-настоящему «требуются». Большая часть скорее предмет договорённости. Наше понимание пространства проблемы углубляется и изменяется по мере того как улучшается наше понимание пространства решения и пространства ограничений (планы, экономика, реальность).

Где истоки водопада? Читаем статью «Управление разработкой больших компьютерных систем»

Вам знакома эта картинка?

WaterfallClassic

Ну конечно, это визуализация всем известной каскадной методологии разработки ПО, иначе именуемой «водопадом» (en: Waterfall). Той самой, которую так принято критиковать последние лет 20 и изобретать взамен модные итеративные и агильные методологии. А вы знаете, откуда взялся этот водопад?

История

Традиционно ссылаются на статью Уинстона Ройса (Winston RoyceManaging the Development of Large Software (Управление разработкой больших компьютерных систем). Но мало кто читал эту статью. А если её прочитать, то выяснится, что Ройс и не обосновывал водопад, и не рекомендовал его и даже не придумал его. Вышеприведённая картинка у Ройса просто иллюстрирует естественную последовательность шагов при реализации компьютерной системы — требования, анализ, дизайн, кодирование, тестирование — ну, как положено.А дальше Ройс пишет, что нельзя строить проект буквально как на картинке, последовательно выполняя фазы, и не переходя к следующей фазе, пока не завершится предыдущая. Более того, всю статью Ройс посвятил потому, чтобы показать, как надо видоизменить модель разработки, чтоб, пользуясь ею, реально можно было выполнять большие проекты.

Перевод

Мне так понравилось, что я решил сделать перевод на русский язык, который с удовольствием представляю вашему вниманию:

Уинстон Ройс, Управление разработкой больших компьютерных систем, 1970 год

Продолжить чтение «Где истоки водопада? Читаем статью «Управление разработкой больших компьютерных систем»»

Достаточно гибкости?

Написано в декабре 2009

Мы являемся свидетелями большой шумихи вокруг гибких процессов разработки (Agile Software Development, [1]). Термин, введённый разработчиками, распространился в мире ПО и за его пределами и используется часто не по назначению. Сегодня все «агильные», а быть «неагильным» просто стыдно. Сам будучи разработчиком пару лет назад, я зачитывался книгами Кента Бека [2] и Мартина Фоулера [3]. Книги замечательные. Эти люди создали очень эффективные методологии разработки ПО. Со смещением моего фокуса в сторону управления проектами, я научился видеть методологии разработки в бизнес-контексте и, в том числе, видеть границы применимости гибких методик. Некоторыми мыслями я хочу поделиться с этой статье.

Начальные условия

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

В нашей фирме несколько десятков программистов. Мы занимаемся индивидуальной разработкой преимущественно веб-приложений с использованием новейших технологий. В каждый момент времени у нас пара десятков актуальных проектов на разных стадиях цикла разработки. За все время существования фирмы были завершены сотни проектов. Наш типичный проект длится 3-6 месяцев, в команде 3-6 человек. Практически все контракты имеют фиксированную стоимость. Продолжить чтение «Достаточно гибкости?»

Варианты использования вариантов использования

Написано в декабре 2009

Каждый проектировщик информационных систем рано или поздно сталкивается с вариантами использования (ВИ, англ. — use cases). Но в результате часто случается так, что эта полезная техника используется не по назначению и не приносит ожидаемой пользы. В чём же дело, и как писать варианты использования эффективно?

Алистэр Коуберн [1] еще пять лет назад сказал всё в своей статье «Варинаты использования, десять лет спустя» [2]. Я же здесь попытаюсь лишь добавить несколько практических аспектов из своего личного опыта. Я исхожу из того, что читатель знаком с ВИ (если нет – рекомендую книгу того же Алистэра Коуберна «Writing Effective Use Cases» [3]).

С помощью ВИ можно описать взаимодействие системы с окружающим миром и, таким образом, лучше понять систему. Т.е. ВИ можно рассматривать как один из способов описания требований к системе (система должна быть такой, чтобы поведение, видимое снаружи, было таким, как описано в ВИ). В предыдущем предложении ключевыми словами являются «один из». Существует огромное количество способов записать различные требования к системе, и ВИ – лишь один из них,  подходящий лишь для определённого типа требований в определённых условиях. Использованные удачно, ВИ компактно и понятно опишут систему. Использованные вне области применимости, ВИ отнимут время как у автора, так и у читателя и не привнесут большей ясности.

Полный текст статьи в PDF

Выводы

Варинаты использования принесут вам пользу, если:

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

И опять GTD

 

Еще в 2005 году я натолкнулся на методику доведения дел до конца (Getting Things Done), разработанную Дэвидом Алленом (David Allen). С тех пор я люблю GTD нежною любовью, хотя и не всё мне удалось реализовать (в частности, я так и не научился побеждать поток корпоративной электронной почты, о чём я может быть ещё напишу).

И вот на днях я натолкнулся на Максима Дорофеева, который уже больше 5 лет с воодушевлением пропагандирует GTD как в Сети, так и за её пределами, за что ему большое спасибо. Версия GTD от Максима называется «Джедайская техника пустого инбокса».

Попытаюсь здесь собрать ссылки на материалы Максима:

Встреча группы Requirements Engineering ASQF

В четверг 21.04.2016 ездил в Эрланген на встречу группы Requirements Engineering при ASQF.

Собралось примерно 20 человек. Докладчик — Werner Motzet — делился своим разнообразным опытом управления командами, прежде всего — агильными. Тема была заявлена как «взаимодействие инженерии требований и управления проектами», но по факту разговор шел о массе других вопрос — связанных и несвязанных с основной линией. В свои 63 года Werner сталкивался со многим и с большим желанием делится своими впечатлениями.

Автор очень горячо рекомендовал книгу Agile Teams lösungsfokusiert coachen, так что я её сразу заказал.

ASQF — Ассоциация специалистов в области качества ПО и профессионального образования.

При ней есть несколько рабочих групп, в т.ч. по Requirements Engineering и Project Management.

ASQF — один из основателей института iSQI, который занимается обучением и сертификацией компьютерных специалистов. (В частности, у меня есть их сертификат QAMP — Quality Assurance Management Professional.)

Следующие встречи группы Requirements Engineering — 9 июня и 14 июля (потом уже после летних каникул).

Читаем статью «Место тестирования среди методов оценки качества ПО»

http://www.software-testing.ru/library/5-testing/117-2008-10-13-19-25-13

Статья 2008 года, но, мне кажется, состояние дел не очень изменилось.

Статья рассматривает несколько моделей качества ПО и останавливается для практических целей на ISO-9126Список целей и аттрибутов качества по ISO-9126:

  • Функциональность
    • Пригодность к определенной работе(suitability)
    • Точность, правильность (accuracy)
    • Способность к взаимодействию (interoperability)
    • Соответствие стандартам и правилам (compliance)
    • Защищенность (security)
  • Надежность
    • Зрелость, завершенность (обратна к частоте отказов) (maturity)
    • Устойчивость к отказам (fault tolerance)
    • Способность к восстановлению работоспособности при отказах (recoverability)
    • Соответствие стандартам надежности (reliability compliance, добавлен в 2001)
  • Практичность, удобство использования
    • Понятность (understandability)
    • Удобство обучения (learnability)
    • Работоспособность (operability)
    • Привлекательность (attractiveness, добавлен в 2001)
    • Соответствие стандартам практичности (usability compliance, добавлен в 2001)
  • Эффективность
    • Временные характеристики (time behaviour)
    • Использование ресурсов (resource utilisation)
    • Соответствие стандартам эффективности (efficiency compliance, добавлен в 2001)
  • Сопровождаемость
    • Анализируемость (analyzability)
    • Изменяемость, удобство внесения изменений (changeability)
    • Риск возникновения неожиданных эффектов при внесении изменений (stability)
    • Контролируемость, удобство проверки (testability)
    • Соответствие стандартам сопровождаемости (maintainability compliance, добавлен в 2001)
  • Переносимость, мобильность
    • Адаптируемость (adaptability)
    • Устанавливаемость, удобство установки (installability)
    • Способность к сосуществованию с другим ПО (coexistence)
    • Удобство замены другого ПО данным (replaceability)
    • Соответствие стандартам переносимости (portability compliance, добавлен в 2001)

Продолжить чтение «Читаем статью «Место тестирования среди методов оценки качества ПО»»

Business Analysis Summit on 2015-09-25 in Frankfurt

Business Analysis Summit (http://business-analyse-summit.com) took place in Frankfurt on 2015-09-25. It is the 2nd such summit organized by German and Austrian chapters of IIBA (https://www.iiba.org/, International Institute for Business Analysis). (The first summit was in 2013 in Salzburg.)

Visitors were ~100 people.

Subjectively they are mostly:

  • From bigger companies
  • With the „customer“ and „developer“ in the same company
  • From financial and automotive sectors
  • Wearing suits.

„Business Analysis“ and „Requirements Engineering“ describe largely the same area, whereas BA focus is on analyzing the processes (Business) (and Requirements are for them just output) and Requirements Engineering is all about handling requirements during the project; for them Requirements are an input. In the daily work, the areas are greatly overlapping and the title mostly depends on company’s tradition.

The language of the summit was (mostly) German.

IIBA German Chapter

http://germany.iiba.org

Exists since 2010. Accepted by IIBA as a chapter officially just 2015.

31 members so far (to become a member first register as a member @IIBA and then apply to German chapter additionally – additional 20 EUR / year).

Next summit is planned for 2017 in Austria.

PMI has recently also activities and a certification program on the field of Business Analysis.

Conclusion

It is good to visit such events from time to time to get a fresh view. Продолжить чтение «Business Analysis Summit on 2015-09-25 in Frankfurt»

Овощи-фрукты, прочие продукты

Статья написана 27.04.2012.

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

ObstGemueseДавайте сначала разберемся, что такое вообще «овощи» и «фрукты».

Порыскав по энциклопедиям, мы выясним, что вопрос задан некорректно.

Начнем с овощей. Выясняется, что термин овощи слабо относится к ботанике. Он определяется как съедобные части травянистых растений. Съедобность, конечно, с точки зрения человека. Поэтому термин этот – больше кулинарный. Некоторые определения идут дальше и считают овощами «любую твердую растительную пищу, кроме фруктов, круп и орехов». Травянистые растения – это те, что не кусты и не деревья. Те, у которых стебли и листья отмирают в конце вегетационного периода. Большинство овощей — однолетние растения. Но бывают и двулетние (а может и многолетние). Хотя у таких на второй год семена созревают, а то, что мы у них едим («съедобные части») созревают в первый год. Очень хочется назвать эти части – плодами. Но это будет ботанически неверно. Органы растений в ботанике как раз хорошо классифицированы: корень, стебель, лист, цветок, плод и т.д.

Что мы едим у овощей? По-разному. Корни (морковь, свекла), стебли (ревень), листья (салат), цветки (цветная капуста), плоды (томат, огурец, арбуз).

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

А что мы едим у картофеля? Понятно — клубни. А что такое клубни? Нет, не корни. Это стебли! Клубень картофеля – это модифицированный подземный побег, утолщенный, с редуцированными листьями. Плоды же картофеля – это маленькие зелененькие ядовитые ягодки, созревающие из цветков и напоминающие помидоры (картофель и томат – близкие родственники, относящиеся к одному и тому же роду – паслён).

Кстати, в чем разница между томатами и помидорами? Очень просто: помидорами называют плоды растения томат. Но это по-русски. По-итальянски сам томат называется pomodoro.

Теперь займёмся фруктами. Что это за фрукты? Это сочные съедобные плоды дерева или кустарника. Замечаете разницу? Плод – это часть растения, ботаника. Фрукт – это уже не ботаника, это опять кулинария. И вообще – не во всех языках. В немецком, например, тоже есть Obst (фрукты) и Frucht (плод). А вот в английском есть только fruit и для плодов вообще и для фруктов.

Яблоки, например, — фрукты. Вишня и малина – тоже. Орехи хоть и являются плодами дерева, но не являются сочными, потому – не фрукты. Если вы найдете кусты со съедобными листьями, то они также не будут являться ни овощами ни фруктами. Земляника получается не фрукт, потому что она травянистая, а не дерево и не кустарник. Ее можно успешно зачислить в овощи, как съедобный плод травянистого растения. Минуточку, скажете вы. Как это земляника – овощ? Она же ягода!

А что такое ягода? А это, оказывается, разновидность плода. Т.е. опять ботаника. Какие бывают плоды? Самые разные. Например – костянка (вишня, слива, персик), яблоко (такой плод не только у яблони, но и у груши, айвы и рябины), орех (лещина, фундук). Ягода – тоже один из типов плода. Ягода – это «многосеменной плод с тонким кожистым внеплодником, сочным межплодником и твёрдым внутриплодником, который образует твёрдую семенную кожуру». Ягодой является плод крыжовника, смородины, винограда. Малина? Нет, плод малины ягодой не является! Он представляет собой сложный плод, состоящий из множества маленьких костянок. Плод малины – многокостянка! Но земляника-то точно ягода? Нет! Плоды земляники (орешки!) — мелкие, коричневатого цвета — находятся на поверхности разросшегося сочного цветоложа (ложной ягоды), часто неправильно называемого ягодой. Зато плод томата – помидор – является настоящей ягодой!

Договорились мы до того, что термин ягода, используемый в ботанике, очень косвенно перекликается с тем, что мы в быту понимаем под ягодами. В быту ягодой, как правило, называют любой мелкий мякотный плод (вне зависимости от его ботанической классификации типа плода и истинности), например, смородина, крыжовник (ягода), клубника, земляника, шиповник (ложная ягода), вишня, черешня, малина (костянка). В то же время, плоды большого размера в быту, как правило, не ассоциируются с ягодами (даже если с ботанической точки зрения они ими являются), например, помидор, баклажан, банан, киви. «Бытовые» ягоды могут быть фруктами (смородина, вишня), а могут и не быть (земляника, костяника).

Отдельно хочется сказать о клубнике и землянике. Земляника – это род растений (Fragaria) семейства розовых. Один из видов этого рода – земляника лесная. Другой — земляника садовая (у которой в свою очередь выведено огромное множество сортов). Третий вид – это земляника мускусная или мускатная или клубника. В быту часто – ошибочно – называют клубникой садовую землянику. Еще одно часто встречаемое слово – «Виктория» — это название одного из сортов садовой земляники.

И вот мы подходим к арбузу. Кто же он? Поскольку арбуз обыкновенный – однолетнее травянистое растение, а в его съедобности мы не сомневаемся, то арбуз – овощ. В пищу мы употребляем плод арбуза, который называется … тыквина (также как и у огурца, дыни и тыквы)! Мнение о том, что арбуз – это ягода оказывается ошибочным.

Что касается тыквенных, то есть еще терминологическая путаница между русским и украинским языками. Украинский «гарбуз» — это тыква. Русский «арбуз» по-украински «кавун». Словом «кабак» называют тыкву в южной России. А русский кабачок – это вполне определенный подвид тыквы обыкновенной.

Вот такие пироги…

Читаем книгу «Abenteuer Software Qualität»

3788Abenteuer Softwarequalität

Kurt Schneider

ISBN: 978-3-89864-784-7

dpunkt.verlag

На немецком языке

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

Используется определение качества по ISO 8402 (Quality Management and Quality Assurance) (здесь мой вольный перевод на русский):

Качество продукта — это степень соответствия этого продукта предъявляемых к нему явных и неявных требований.

Продолжить чтение «Читаем книгу «Abenteuer Software Qualität»»