Отправляет email-рассылки с помощью сервиса Sendsay

Из программистов в руководители

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Бизнес с высокой прибылью" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Ноябрь 2003   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Автор
Симон Молдавский

Статистика

1.763 подписчиков
0 за неделю
←   Все выпуски   →

ИЗ ПРОГРАММИСТОВ В РУКОВОДИТЕЛИ


Информационный Канал Subscribe.Ru
Из программистов в руководители
Выпуск 11: Управление рисками; конфигурационное управление

 

Присылайте нам вопросы по программной инженерии и управлению программными проектами, и на них ответят наши эксперты - преподаватели Учебного Центра UkrSoftPro.

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

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

Отвечает Дмитрий Безуглый, АО "Банкомсвязь":

С точки зрения теории здесь применимо управление рисками (что на самом деле и происходит - тот, кто сталкивался с серьезной проблемой, тот на нее и "закладывается"). Берем enhancement request (или supply requirement), анализируем риски, с которыми связано предлагаемое решение, и если есть допустимый workaround или риск того не стоит, документируем его и просто игнорируем. Если риски значительны с точки зрения пользователя или по другой причине (например, полная потеря данных), то придется раскошелиться на обработку. А вот вопрос, связанный с увеличением при этом сложности системы, зависит от архитектурных и проектных решений.

Если заказчик что-то поменял, скажем, в базе данных, то последствия таких действий непредсказуемы; он легко может в ходе дальнейшей работы потерять все или часть данных. Это вовсе не значит, что я должен (если это не оговорено контрактом) вставлять в свое приложение функциональность резервирования данных.
Какие из рисков, связанных с эксплуатацией программного обеспечения, должна в таких случаях брать на себя компания-разработчик (и, соответственно, инвестировать деньги и время на их предотвращение, mitigation)? Какие риски остаются в сфере ответственности заказчика?
Часть рисков официально "поделена" контрактом: "в случае ... система должна обеспечить ...". Часть берется на себя разработчиками потому, что "так принято" - принято корректно обрабатывать и выдавать сообщения о некорректном вводе данных пользователем и т.п. Наконец, часть рисков остается на совести заказчика.
Но, вероятно, в подавляющем большинстве случаев заказчик понятия не имеет - что это за риски, за которыми он должен следить. Интересно, существуют ли какие-то стандартные подходы для определения пределов ответственности разработчика?

Отвечает Дмитрий Безуглый, АО "Банкомсвязь":

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

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

В связи с развитием идей continuous integration складывается такое впечатление, что какие-то продвинутые стратегии configuration management становятся не очень нужны. Просто все всегда работают с самыми последними ("head") версиями файлов, а продукт автоматически собирается каждые два часа и таким образом оперативно выявляются нестыковки. Ваше мнение?

Отвечает Евгений Пророк, UkrSPIN:

Continuous integration у нас является частью codeline policy для active development line. В то же время параллельно существуют ветки типа task branch, release codeline, release-prep codeline, в которых не всегда имеет смысл использовать эту практику и где более оправданно применение "продвинутых стратегий" типа jobs в используемом нами Perforce. Но я согласен с тем, что в более простых случаях (первые версии продукта, небольшая команда, отсутствие кастомизированных версий для отдельных клиентов - тип проектов, хорошо подходящий, например, для экстремального программирования) вполне можно ограничиться continuous integration, и это будет работать.

Приведенная мной терминология была взята из книги Software Configuration Management Patterns: Effective Teamwork, Practical Integration By Stephen P. Berczuk, Brad Appleton. Даю краткий словарик:

  • continuous integration - "Integrate every change team members make as soon as they make it";
  • codeline - "A codeline is a progression of the set of source files and other artifacts that make up some software component as it changes over time. Every time you change a file or other artifact in the version control system, you create a revision of that artifact. A codeline contains every version of every artifact along one evolutionary path.";
  • codeline policy - "the codeline policy explicitly states the rudimentary policies an organization has about how to conduct concurrent development and how to manage releases";
  • active development line - один из паттернов конфигурационного управления ("An active development line will have frequent changes, some well-tested checkpoints that are guaranteed to be "good," and other points in the codeline that are likely to be good enough for someone to do development on the tip of the line.");
  • task branch - еще один паттерн ("this pattern describes how to reconcile long-term tasks with an active development line");
  • release codeline - еще один паттерн ("this pattern shows you how to isolate released versions from current development");
  • release-prep codeline - еще один паттерн ("Create a release engineering branch when code is approaching release quality. Finish the release on this branch, and leave the mainline for active development. The branch becomes the release branch.");
  • Perforce - "commercial version control tool with outstanding support for branching and merging. It bills itself as the "fast software configuration management system".

Наша рассылка поднимает широкий круг вопросов, включающих управление требованиями и проектирование ПО, конфигурационное управление и управление качеством, планирование и мониторинг проектов, управление ресурсами и коммуникациями, стандарты по организации производства ПО, процессные методологии Rational Unified Process, Microsoft Solutions Framework, eXtreme Programming и др., методологии обследования организаций SEI CMMi, ISO 9001, SPICE и др.

Если у вас возникают вопросы, относящиеся к этим дисциплинам, пишите нам на адрес edu@ukrsoftpro.com.ua, и мы постараемся ответить на них в следующих выпусках рассылки.

Украинский Учебно-Практический Центр Программной Инженерии UkrSoftPro

 http://www.ukrsoftpro.com.ua


Консалтинг, аудит, тренинговые программы
Дистанционная учебная программа "Профессионал Управления Программными Проектами"

 подробнее http://www.ukrsoftpro.com.ua
http://subscribe.ru/
E-mail: ask@subscribe.ru 		Отписаться
Убрать рекламу
В избранное