76

Системный Анализ и Требования / Re: Относится ли данное требование к "нефункциональным"?

« : 04 Ноября 2008, 23:58:13 »

Коллеги, у нас тут возник неординарный вопрос.

Стоит маленькая подзадача, которая послужила причиной большой дискуссии. Надо распределить требования по категориям: "Функциональные" и "Нефункциональные". И нам пытаются навязать мнение, что требование "Система должна предоставлять возможность формирования списка пользователей, с предоставлением уникального имени, пароля для доступа в интерфейс, указания групп и их статуса." - НЕфункциональное. Я считаю, что это требование - функциональное.

А вы как думаете?

IMHO требований здесь - как минимум два. Одно - функциональное, "Формирование списка пользователей", его лучше описать вариантами использования; для его тестирования нужны тест-кейсы. Другое , "Свойства пользователя", можно отнести как к функциональным, так и к нефункциональным: вероятно, оно будет влиять на другие, и будет нуждаться только в формальных проверках.

Дело в том, что список свойств вероятнее всего будет изменяться и уточняться (что такое уникальное имя? ФИО или логин? как хранить пароль - в хешах? может ли пользователь входить в несколько групп, и что в этом случае делать с его полномочиями? что если у нескольких пользователей одинаковые ФИО, и что если пользователь меняет ФИО? нужно ли хранить email, телефон, фото? и проч.).

Если в системе будет более 100 пользователей, управление их учётными записями тоже станет не такой тривиальной задачей (можно ли удалить единственного пользователя с полномочиями давать полномочия? а если он уволился, и никто не знает его логина с паролем? и проч.). Это тоже нужно серьёзно уточнять.

Совмещать две эти области знаний (требований? решений?) в одном требовании я бы не стал.

77

Сообщество Аналитиков / Re: Бесплатный билет на семинар Владимира Павлова

« : 23 Октября 2008, 11:51:33 »

Вдогонку: если кто не боится моего почерка - вот мой конспект (tiff->zip). Спрошу Владимира о том, можно ли выложить презентацию и звукозапись (~200 Мб) с семинара. Презентации, кстати, у меня в электронном виде нет.

78

Сообщество Аналитиков / Re: Бесплатный билет на семинар Владимира Павлова

« : 23 Октября 2008, 00:09:32 »

Александр, большое Вам спасибо! Семинар - как раз то, что мне было нужно, как раз в тему задач, которые я сейчас решаю на работе.

Отчёт о семинаре Владимира Павлова.

1) Семинар начался издалека - с того, что среди Top 500 предприятий средний годовой оборот на отдного сотрудника ~$1 млн., средняя чистая прибыль на сотрудника - ~200 тыс. (эх... к вопросу о Карле Марксе, эксплуатации и эксплуатируемых), что самые прибыльные - правильно, oil & gas, чуть менее - software, ещё менее - retail, и что для того, чтобы просто не терять позиций, нужно расти на 30% в год, а делать это можно только за счёт повышения эффективности

2) Дальше Владимир рассказал об идее обратной семантической трассировки. Вкратце - допустим, Вам нужно перевести маркетинговые материалы с русского на японский. Как Вы можете проверить правильность перевода, если не умеете читать иероглифы? Правильно, сначала дав одному переводчику перевести с русского на японский, потом другому - обратно, с японского на русский, и сравнить смысл (семантику) полученного текста с исходным. А разработка ПО, да и любая работа - по сути цепочка переводов: из требований в архитектуру, их архитектуры - в код и т.д.

3) Затем мы некоторое время привыкали понимать друг друга без слов - игрой в пантомиму.

4) После этого Владимир разделил нас на две команды, запретил говорить, выдал задания и... мы принялись разрабатывать архитектуру систем, общаясь исключительно рисунками на UML, ну и ещё иногда мыча друг на друга. А потом обменялись архитектурами и постарались понять, какая у другой команды была задача, какое решение она предлагает и что в этом решении неправильно.

Что выяснилось: 2 команды из 4 человек с разными бэкграундами, впервые видящих друг друга, способны за 3 часа молча разработать на UML вполне сносную и целостную архитектуру для решения весьма сложных задач. Молча самоорганизоваться, описывая роли друг друга на UML. Написать use case view, analysis view, static view, dynamic view, component view, deployment view.  Эта архитектура оказалась вполне отчуждаемой, её можно было понять и прорецензировать без присутствия автора. Она была достаточно прагматичной, чтобы её можно было реализовать, по крайней мере, после детализации. Всё понятно, как делать, нужен капитал .

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

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

Семинар НЕ имеет дела с глубинами архитектуры, применением паттернов.

Семинар НЕ имеет дела с академически правильным применением UML: на практике это делать некогда. UML в нём представляется как живой язык, не такой красивый, но куда более быстрый и понятный, нежели литературный.

Участники были разными. Особенно запомнился скептик, высокопоставленный архитектор, утверждавший, что архитектура имеет слабое отношение к реализации (а зачем она тогда нужна?), и что UML для описания архитектуры больших систем не подходит (а на чём тогда описывать? ERD + DFD + block лучше? или лучше кондуит в 1000 страниц без единой картинки? или решение должно быть документировано на языке C++?). Ну и ещё был разработчик, очень хотевший проявить себя, постоянно споривший на пустом месте. Но Владимир мастерски модерировал теоретическую часть, а практические задания все выполняли на удивление дружно и слажено.

79

Системный Анализ и Требования / Re: Анкета для сбора требований

« : 01 Сентября 2008, 23:23:37 »

Мне необходимо составить анкету для сбора требований к уже существующему ПО.
(Вобщем то собрать с пользователей пожелания и замечания)<...>

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

80

Бизнес-анализ и Целеполагание / Re: Начало в описании БП.

« : 12 Июля 2008, 01:19:22 »

ARIS Toolset это программа в которой возможно моделирование бизнес процессов?
а где такую можно скачать/купить?

Купить - у IDS Sheer AG, но "удовольствие" это дорогое, до десятка тысяч долларов за рабочее место. Скачать тоже трудно: очень специфическая вещь.
Есть хорошая новость: ARIS - это ещё и методология с нотацией. Главное знать, что делаете, а рисовать можно и в Draw, писать - в Write, вести словари и считать - в Calc.

81

Управление Проектом / Re: Руководитель проекта, как им стать?

« : 28 Июня 2008, 21:50:23 »

Думаю хороший руководитель проектов - это профессионал в своей области

Эх, мои наблюдения не всегда это подтверждают. Как стать:

Путь 1, видел 4 раза:
1) Работать в любой области, или совсем не работать
2) Быть другом или родственником руководителя департамента R&D

Путь 2, видел 2 раза:
1) Быть весьма посредственным программистом
2) Много и громко говорить общие вещи, спихивать свои невыполненные задачи на других
3) Уметь закадычно общаться с начальством, говорить начальником только "да", "вы правы", "великолепное решение", далее GOTO Путь 1

Путь 3, видел 1 раз (проект - консалтинговый)
1) Уметь много, но не очень красиво и убедительно говорить общие слова, опыта не иметь
2) Быть первым, кого увидел ген. директор при разговоре о том, что проекту быть

и "хороший политик" в одном лице.
Причем больший акцент делаю на втором пункте.

Тоже не всегда.

Путь 4, видел 1 раз
1) Быть классным, опытным, вдумчивым программистом, порой говорить начальству "нет", и даже "вы некомпетентны"
2) Дождаться, пока действующий менеджер проекта уйдёт
3) Проект должен "гореть", так, чтобы руководитель R&D понимал: если всунуть "своего" незнайку, проект провалится, и уволят и его, и незнайку
4) Понять, что эта возня с хождениями "на ковёр", бумажками и подгонкой планов не по душе, и отвергнуть предложение стать PMом

82

Обучение / Re: основные критерии успешного аналитика

« : 28 Июня 2008, 20:53:21 »

IMHO "из института" аналитика или архитектора, в отличие от разработчика или тестировщика, взять нельзя.
Системным аналитиком можно стать из разработчиков, тестировщиков, консультантов службы тех. поддержки.
Бизнес-аналитиком можно стать из "предметников", системных аналитиков, пресейлов.
"Из института" можно стать начинающим тестировщиком, начинающим разработчиком, эникейщиком поддержки или начинающим исполнителем, изучающим предмет.

Во-первых, что значит "успешный"? Американскую мечту "много денег, машина, все дела"? Кто хочет только денег - получает в лучшем случае только деньги. Работающая система, облегчающая людям жизнь? С этим сложнее, надо иметь упорство и трудолюбие. Уважение? С этим ещё сложнее, для этого надо много напрягаться, помогать людям, и от денег оно мало зависит.

Во-вторых, будьте скромнее. Намного скромнее. Поверьте, практика ценится не только буржуями, она - критерий всего.
Самой себя хвалить - дурной тон. Кичиться связями родителей - тоже. И своих руководителей обвинять в некомпетентности, самостоятельно не сделав ни одной полезной системы от начала до конца - не следует. Не задумывались, почему ваша руководительница соглашается и улыбается? Был у нас когда-то случай: дочке крупного заказчика захотелось работу, её посадили на козырное место, дали гламурный ноутбук и весьма приличную з/п из по сути из папиных денег, и поручили делать что-то совершенно бесполезное, а ей расписали - как очень важное. И со всем, что она делала, соглашались, лишь бы не мешала. Сертификат сертификату - рознь, российским сертификатам, в т.ч. бумажкам о высшем образовании в громких ВУЗах, цена вообще сомнительная. Без скромности и трудолюбия растить вас в аналитики вряд ли кто-то возьмётся.

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

Только без обид, мнение сугубо субъективное, просто сказал, что думал.

83

Бизнес-анализ и Целеполагание / Re: Начало в описании БП.

« : 25 Июня 2008, 00:04:48 »

Начало в описании БП"

Начинать стоит с рамок описываемой деятельности, далее - переходить к цепочке создания прибавочной стоимости / полезности (последнее - для обеспечивающих БП или БП гос. организаций).

И сразу вопрос: может есть у кого образец описания БП телекоммуникационной компании.

eTOM (мне не нравится - не даёт ответ на вопрос "откуда берутся деньги?", а ведь от этого всё отталкивается), SAP for Telecommunications (всё наоборот, не даёт ответа на вопрос "какие средства используются").

И в какой программе лучше делать описание, тоже интересно.

Мне нравится ARIS Toolset.

Само описание можно в Word делать, я так понимаю?

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

84

Системный Анализ и Требования / Re: Управление требованиями при их разработке внешней компанией

« : 25 Мая 2008, 23:50:54 »

Возможно, имеет смысл завести СУТ для относительно редко изменяющихся высокоуровневых бизнес-требований, количество которых измеряется десятками, а также первичных документов, из которых они взяты (протоколов интервью, схем БП, анкет, регламентов, бланков и т.д.). И требовать от исполнителей общаться по бизнес-требованиям только через эту СУТ. В качестве подобной СУТ подойдёт практически любая wiki-подобная система. Например TikiWiki (http://info.tikiwiki.org/tiki-index.php), в ней поддерживается история редактирования.

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

85

Консалтинг и Внедрение / Re: Консалтинг: что, как, каким образом

« : 16 Апреля 2008, 16:40:20 »

Мне известны случаи, я даже думаю что это не редкость, когда IT-директор
сам себе консалтинг проводил и выбирал систему исследуя информационный рынок. Это конечно
же не лучший вариант, пускай даже у роководителя есть определенный опыт в мероприятиях
подобного рода, просто в данном случае мы получаем субъективную оценку компании в целом.
Используя внешних консультантов, конечно с учетом их профессионализма, возможно получить
гораздо более независимую оценку, о том заказывать ИС или брать готовое решение, и к тому
же какое решение выбрать с учетом материальных возможностей. По результатам работы консультнов (причем к моему удивлению,
в практике встретился с названием Научно-исследовательская работа, уж не знаю правильно
это так понимать или нет) делается выбор, предположим ПК Галактика. Это все конечно
вода-водой, давай действительно попробуем разобрать поэтапно эту курсовую...

Судя по моему не слишком большому опыту в этой сфере, всё происходит несколько иначе.
Консультанты чаще всего ангажированы. Они знают, что если они приведут к покупке системы A - им перепадёт $ X, B - $ Y. Соттветственно, как бы хороша ни была система C, они никогда даже не посмотрят в её сторону.

86

Консалтинг и Внедрение / Re: Сколько стоит внедрение OpenSource?

« : 16 Апреля 2008, 16:17:44 »

<...>И нам тоже не плохо, так как конфигурация и/или дописование OpenSource полегче(читай гибче), чем продукты MS,которые если нужна какая-то специфичная функциональность то надо платить.(если она конечно есть эта функциональность)

Вместо того, чтобы дописывать Open Source-системы до состояния коммерческих, программисты могли бы заниматься чем-нибудь, что приносит компании деньги. Лучше, чем у MS, у них может получиться, но дешевле - вряд ли. Да, они получат удовольствие, но компания заплатит за это упущенной прибылью.

87

Бизнес-анализ и Целеполагание / Re: Что-то тихо в eTom лесу !!!

« : 11 Апреля 2008, 14:01:30 »

Модель eTOM - просто одна из референтных моделей бизнес-процессов для телекоммуникационных компаний. Т.е. при моделировании/разработке бизнес-процессов полезно обращать на те существующие бизнес-процессы, которые сильно отклоняются от eTOM. Такое отклонение - повод пересмотреть БП. Ну или пересмотреть eTOM .

88

Варианты Использования (Use Case) / Re: Розенберг против Коберна

« : 30 Марта 2008, 19:14:19 »

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

А сказать я хотел следующее: экономией времени на проектировании очень часто оправдывается лень и авторитаризм. Да, описание UC может быть в разной степени полным и формальным, в зависимости от масштаба проекта и использования аутсорсинга, но совмещать его с изложением реализации (экранных форм) IMHO очень вредно: трудно делать всё сразу, "за один шаг", и при этом хорошо. Невозможно проверить ответ задачи (архитектуру, в т.ч. формы), не увидев её условия (требований, в т.ч. UC).

89

Варианты Использования (Use Case) / Re: Розенберг против Коберна

« : 30 Марта 2008, 04:12:36 »

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

Коберн предлагает сначала создать ВИ, потом спроектировать взаимодействие с системой и дизайн UI. Результаты каждого из шагов наверняка нужно обсуждать, защищать и пересматривать. Для этого PMу надо признать, что системный аналитик не способен идти дальше UC - по крайней мере, не останавливаясь для проверки и согласования.

А теперь представьте себе: небольшая команда. Есть начальник Он всегда есть - даже формально "все равны", иначе анархия. В небольшой проектной команде начальник, обычно, молодой и горящий желанием доказать всему миру своё превосходство. Он считает, что лучше всех всё знает, и всеми силами постарается взять на себя всю работу, связанную с принятием решений. Он может попытаться подмять под себя требования ("я заставлю пользователей этого хотеть"), варианты использования ("я сам знаю, как всё должно происходить"), взаимодействие ("для меня удобно реализовать - значит, для всех удобно использовать"), дизайн ("только у меня идеальный художественный вкус и чувство гармонии"). Может попытаться вмешиваться даже в маркетинг и ценообразование, но это уже диагноз. А так как столько дел делать долго и скучно, а сроки поджимают - приносится в жертву обсуждение, детализация, качество. Вот и появляется желание всё объединить, чтобы поменьше признавать необоснованность и авторитарность своих решений. Если начальник достаточно умный, умеренный и "кодирующий" - в результате может появиться неплохой "танцующий медведь", которым он будет всюду хвастаться.

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

90

Управление Проектом / Re: Руководитель проекта, как им стать?

« : 27 Марта 2008, 22:54:16 »

<...>

Странный пост. Вообще-то ПМ - человек по определению жёсткий. Он заставляет работать, принимает неприятные прагматичные решения, "наступая на песню" турбулентного потока сознания аналитиков, технологических изысканий программистов, ленивой сказки про "ничего не работает" тестировщиков. В тяжёлых случаях - ставит на место. Это может показаться безразличием или оскорблением. Зачем по этому поводу переживать?