Archive for Декабрь 2009
Директор информационной службы – ссылка и обзор
Раздел ссылок «Периодика» я начинаю с журнала «ДИРЕКТОР ИНФОРМАЦИОННОЙ СЛУЖБЫ».
Почему? Во-первых, это издание «родилось и выросло» буквально на моих глазах. Во-вторых, если продолжать уже начатую тему – разработчик ИТ систем и пользователь, то именно это издание (в отличие от многих современных, предназначенных для разработчиков) публикует много материалов, позволяющих взглянуть на проблемы автоматизации глазами пользователей, являясь при этом журналом, говорящим на «ИТ языке».
Add comment 27.12.2009
Варианты использования вариантов использования
Григорий Грин, декабрь 2009
Каждый проектировщик информационных систем рано или поздно сталкивается с вариантами использования (ВИ, англ. – use cases). Но в результате часто случается так, что эта полезная техника используется не по назначению и не приносит ожидаемой пользы. В чём же дело, и как писать варианты использования эффективно?
Алистэр Коуберн [1] еще пять лет назад всё сказал в своей статье «Варинаты использования, десять лет спустя» [2]. Я же здесь попытаюсь лишь добавить несколько практических аспектов из своего личного опыта. Я исхожу из того, что читатель знаком с ВИ (если нет – рекомендую книгу того же Алистэра Коуберна «Writing Effective Use Cases» [3]).
Add comment 25.12.2009
Разные разные пользователи (продолжение)
А теперь на дворе год 2003
Меня пригласили на уже начатый проект. Пользователи – финансовая организация довольно высокого уровня (отвечает за бюджет области).
Этап разработки технического задания завершен, денежки все получены и естественно потрачены. Идет стадия разработки, и уже пришло время эту разработку закончить и сдать. И уже десант разработчиков и аналитиков высадили прямо в офис Заказчика (благо все происходит в одном городе). Ан до выхода на руководство для сдачи Системы и подписания актов дело никак не доходит.
Начинаю разбираться. И вот какие характеристики этого проекта:
- Проект выполняют внешние разработчики.
- Разработка заказная – и с точки зрения пользователя, и для разработчика.
- Система должна была быть разработана для всей организации, но под конкретную функцию. Причем в реализации этой функции участвуют как значительная часть работников собственно финансовой организации, так и сотрудники других организаций (на отдельных этапах) и их много.
- Инициатором разработки АС являлись сотрудники отдела АСУ финансовой организации.
- В этой организации на тот момент разве что курьеры и уборщицы не сидели за компьютерами – а так все были охвачены. Использовалось несколько разных информационных систем, и очень активно задействованы возможности MS Office.
4 comments 18.12.2009
Достаточно гибкости?
Григорий Грин, декабрь 2009
Мы являемся свидетелями большой шумихи вокруг гибких процессов разработки (Agile Software Development, [1]). Термин, введённый разработчиками, распространился в мире ПО и за его пределами и используется часто не по назначению. Сегодня все «агильные», а быть «неагильным» просто стыдно. Сам будучи разработчиком пару лет назад, я зачитывался книгами Кента Бека [2] и Мартина Фоулера [3]. Книги замечательные. Эти люди создали очень эффективные методологии разработки ПО. Со смещением моего фокуса в сторону управления проектами, я научился видеть методологии разработки в бизнес-контексте и, в том числе, видеть границы применимости гибких методик. Некоторыми мыслями я хочу поделиться с этой статье.
Начальные условия
Для дальшейших рассуждений важно знать, из каких начальных условий я исхожу. В другой среде могут действовать совсем иные законы.
В нашей фирме несколько десятков программистов. Мы занимаемся индивидуальной разработкой преимущественно веб-приложений с использованием новейших технологий. В каждый момент времени у нас пара десятков актуальных проектов на разных стадиях цикла разработки. За все время существования фирмы были завершены сотни проектов. Наш типичный проект длится 3-6 месяцев, в команде 3-6 человек. Практически все контракты имеют фиксированную стоимость.
Принципы гибких методологий
Давайте взглянем на некоторые принципы гибкой разработки, сформулированные в агильном манифесте [4, 5]:
«Нашим главным приоритетом является удовлетворение заказчика посредством ранней и непрерывной поставки работоспособного программного обеспечения.»
Быть может прямо здесь и зарыта собака? Главным приоритетом является удовлетворение заказчика. Звучит логично, но кто этот заказчик?
Add comment 16.12.2009
Разные разные пользователи
Итак, в добавление к условиям, которые необходимо учесть, начиная выстраивать свои отношения с пользователем АС, первым среди которых, напомню, является: «Являемся мы внешним разработчиком или работаем в качестве ИТ специалистов в той же кампании», есть (а вернее был, когда мне пришлось работать) еще и такой:
- Система, которую мы начинаем делать, придет к пользователям, уже сидящим за компьютерами (то есть это увеличение функций – расширение, замена чего-то – улучшение), или это первая встреча пользователей (и в широком и в узком смысле) с компьютерами.
Еще раз к вопросу о термине «Пользователь». Конечно, как почти любое слово в русском языке, этот термин многозначен. Использовав его в качестве замены более общепринятого в среде ИТ специалистов термина «Заказчик», я хотела подчеркнуть более важные для аналитика аспекты отношений и применила понятие Пользователь «в широком смысле» (или с большой буквы). То есть имея ввиду всю организацию, которая будет применять нашу будущую разработку. Если конкретных людей, использующих систему (программный продукт) много, я их пока – условно – буду называть «конечными пользователями».
Хотя в пору АРМов эти понятия совпадали.
А мой сегодняшний рассказ начинается как раз в эту пору.
2 comments 09.12.2009
Ссылка: АП КИТ
Одна из главных черт аналитика – широта взгляда на все, что связано с профессией. Поэтому очень желательно иметь хотя бы самое общее представление о том, что делается в сфере ИТ в целом в стране – что делают крупные компании-монстры, какова позиция государства, как идет развитие ИТ-рынка, каковы тенденции в развитии законодательства, влияющего на ситуацию в сфере ИТ, и в частности в сфере стандартизации. Сейчас есть возможность мониторить все эти вопросы, просматривая всего несколько сайтов в сети.
Например, сайт АП КИТ (некоммерческой Ассоциации Предприятий Компьютерных и Информационных Технологий).
Add comment 07.12.2009
О пользователе замолвлю слово
Поторопиться с этими записками подтолкнул меня сайт «Первая конференция, посвященная работе с требованиями в ИТ-проектах Req Labs 2009» . Это отлично, что случилась такая конференция. Здорово, что можно посмотреть бОльшую часть презентаций (спасибо организаторам, очень интересно). Но я здесь о другом. Среди эпиграфов, красиво сменяющих друг друга в верхней части сайта, есть и такой: «Классика требований заказчика: «Пойди туда, не знаю куда. Принеси то, не знаю что…» Похожие высказывания есть и в докладах конференции, и в других выступлениях аналитиков на конференциях и семинарах. Причем говорится об этом и всерьез, и в шутку (например: «Заказчик никогда не может сказать точно, чего он хочет, ибо ему хочется всего сразу, много и на халяву»).
Вообщем, чувствуется, что у аналитиков наболело. (далее…)
2 comments 05.12.2009
