Оригинал статьи: Iterative and Incremental Development: Brief History (локальная копия на всякий случай).

Авторы: Craig Larman, Victor R. Basili

Опубликована IEEE Computer Society в 2003 году

Бытует мнение, что итеративная разработка — это изобретение 21-го века, присущее агильным методам. А ранее, дескать, был водопад. Авторы статьи показывают, что идеи итеративной инкрементальной разработки (Iterative Incremental Development, IID) уходят корнями в 50-е годы 20-го века, и что в каждой декаде с тех пор наиболее прогрессивные умы успешно применяли IID в своих проектах.

Продолжить чтение «Читаем статью «Итеративная и инкрементальная разработка: краткая история»» →

В Санкт-Петербурге 22.-23.04.2016 прошла конференция Analyst Days.

Программа конференции Analyst Days 2016.

Много интересных докладов, много менее интересных.

Далее перечислены доклады, которые привлекли моё внимание.

Анна Лопатухина, Постоянные переключения контекста в жизни аналитика: как перестать беспокоиться и начать ими управлять.

Ирина Суворова, EA и TFS — история успешного внедрения

Андрей Павлов, EARS: The Easy Approach to Requirements Syntax

Андрей Федорин, Семь правил создания убедительного технического задания

Екатерина Калинина, Как повысить личную информационную эффективность

Никита Селенков, Когда надо заканчивать работу с аутсорсингом

(ещё продолжаю слушать записи, 2016-06-19)

 

 

IREB провела 10.06.2016 виртуальную конференцию iRECON-2016 (International Requirements Engineering Conference). Список докладов (организаторы обещали опубликовать материалы выступлений):

• Keynote State of the art RE @ Digitec Galaxus AG by Mr. Rainer Grau, Head Business Development Digitec Galaxus AG, Switzerland
• RE@Agile — The future of Requirements Engineering in an agile context, Mr. Kim Lauenroth, Ph.D. in Requirements Engineering, First Chair of IREB, Germany and Chief Requirements Engineer at Adesso AG
• The Role of the Product Owner in Agile and its impact on Requirements Engineering, Mr. Shane Hastie, MIM, CBAP, ICE-VM, Chief Knowledge Engineer and Agile Practice Lead at Software Education; Board member of The Agile Alliance»
• Avoid Scope Creep-Discover the REAL Requirements, Mr. Robin Goldsmith, President at Go Pro Management, Inc., and author of Discovering REAL Business Requirements for Software Project Success
• Requirements Toolkit: Top Models for Complete Requirements Analysis, Mrs. Elizabeth Larson, PMP, CBAP, PMI-PBA, CSM, CEO at Watermark Learning
• From Models to Stories: Building Your Agile Requirements Backlog, Mrs. Megan Jackson Stowe Sr. Product Manager, Seilevel
• Software Requirements: 7 Critical Success Factors, Mr. Karl Wiegers, Ph.D. in Chemical Engineering, Principal Consultant at Process Impact and co-author of Software Requirements, 3rd Ed
• Vote of Thanks, Mr. Stefan Sturm, Managing Director of IREB GmbH,

Цитирую анонс издателя от 15.06.2016:

Today, issue 2016-02 of the RE Magazine has been published!

Here is what you will read:

• How Requirements Engineering can benefit from crowds
  by Edward Groen and Matthias Koch
• Modeling Requirements and Context as a means for Automated Requirements Validation
  by Bastian Tenbergen et al.
• Leveraging Creativity Techniques in Requirements Elicitation
  by Áldrin Jaramillo Franco and Saïd Assar
• NLP for Requirements Engineers, Part 2
  by Corrine Thomas and Albena Georgieva (Part 1 in issue 2016-01)
• Managing the Invisible — Ensuring Software Quality beyond Micromanagement
  by Gunnar Harde
• Sharing My Doubts on Acceptance Criteria
  a commentary by Karol Frühauf

Заодно содержание 1-го номера за 2016 год:

Today [29.02.2016] we have published issue 2016-01 of the free online RE Magazine.

Here is what you will read:

• The Genius Toddler Challenge — How to create awareness for some of the difficulties requirements engineers face
  by Manon Penning
• Requirements Engineering in Research Projects: Food for Thought — Lessons learned from a European Framework Project
  by Dr. Christine Grimm and Onur Görkem Özcan
• What makes Women Better BAs — What makes an excellent BA and are women more suited to the role?
  by Sandra Leek
• Evolving and Improving the Requirements Approach to Big Data Projects — A Roadmap to Implementing Big Data Projects
  by Ravishankar Narayanan
• NLP for Requirements Engineers, Part 1 — How requirements engineers can benefit from applying the NLP communication techniques
  by Corrine Thomas and Albena Georgieva
• RE in Agile Projects: Survey Results — Results of research project announced in a previous issue
  by Gareth Rogers

 

 

IREB (International Requirements Engineering Board) поддерживает интересный документ: глоссарий терминов по инженерии требований (последнее обновление в 2014 году) (здесь на всякий случай локальная копия документа).

Кроме 15 страниц определений терминов на английском языке от Acceptance до Walkthrough, он содержит словари для перевода с английского на иностранный и с иностранного на английский для следующих языков:

• Голандский
• Французский
• Немецкий
• Венгерский
• Итальянский
• Польский
• Португальский
• Русский
• Испанский
• Шведский.

Особенно интересно наличие в списке русского языка (начиная со страницы 95).

Статья «What does it mean to say ‘Requirement’?» («Что значит сказать ‘требование’?») от Kim Lauenroth опубликована в первом номере журнала RE Magazine, издаваемого IREB.

В статье автор разбирает понятие «требование» (requirement) и его соотношение с такими понятиями как проблема (problem) или цель (objective) и решение (solution).

Существует такое устойчивый  дуальный образ — дескать, от заказчика поступают требования (или явно, или их помогает формулировать аналитик), а потом разработчики находят и строят решение, соответствующее этим требованиям.Автор предлагает более адекватную модель реальности. Продолжить чтение «Читаем статью «What does it mean to say ‘requirement’?»» →

Fred Brooks, No silver bullet, 1986:

Much of present-day software acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software acquisition problems spring from that fallacy.

В переводе примерно так:

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

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.

По-русски:

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

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

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

История

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

Перевод

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

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

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

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

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

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

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

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