271

Методологии / Re: оформление требований в виде набора таблиц в вордовом документе

« : 24 Октября 2010, 14:18:48 »

присоединюсь к ранее высказавшимся коллегам, в первую очередь к Юрию:
1. Ведение структуры взаимосвязанных требований и представление требований в виде документа (ТЗ) - два разных вида деятельности.
2. Требованиями нужно управлять централизованно, можно делить на независимые разделы и не забывать контролировать интерфейсы между ними. (хватит Вам одного аналитика для этого или нужно несколько - является особенностями Ваших проектов и Вашего наличного личного состава)
3. Требования могут поступать непрерывно (на этом, собственно, и основывается такая организация работы с ними) и, соответственно, их обработка должна происходить также непрерывно или, скажем так, "синхронизированно" с их поступлением.
4. Документ же, представляемый заказчику (в т.ч. с учетом значимости и приоритетов требований) формируется итерациями/релизами, замечания, формируемые заказчиком, меняют не этот документ, а рассматриваются и вносятся в структуру требований обычным порядком (или с учетом их срочности), при необходимости попадают в следующий релиз и т.д. 
5. Для работы с требованиям и формирования документа удобно использовать подходящие средства. Если Вам подходит Ваша табличка - почему нет? Вот только достаточно ли Вам ее? Свой документ на 800 страниц Вы вручную писали?

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

272

Для всех / Re: описание модулей CRM

« : 21 Октября 2010, 12:16:18 »

такой - да!

273

Обсуждение статей / Re: Статья "Методы и средства программной инженерии при проектировании ИИС"

« : 21 Октября 2010, 08:57:42 »

по статье я уже высказался ранее, а вопрос был риторический - нетребующий ответа.

274

Обсуждение статей / Re: Статья "Методы и средства программной инженерии при проектировании ИИС"

« : 20 Октября 2010, 23:00:32 »

4. Тогда лучше использовать понятие модуль или компонента, ну или уровень декомпозиции.

Риторический вопрос: почему все используют в качестве обозначения составной части чего-либо термин "компонента" (ж.р.), имеющий вполне конкретное математическое значение, в отличие от термина "компонент" (м.р.), как раз имеющий необходимое по смыслу значение?

http://www.gramota.ru/slovari/dic/?word=%EA%EE%EC%EF%EE%ED%E5%ED%F2%E0&all=x
http://www.gramota.ru/slovari/dic/?word=%EA%EE%EC%EF%EE%ED%E5%ED%F2&all=x

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

275

Проектирование / Re: Проектирование БД. Логический уровень

« : 20 Октября 2010, 00:28:15 »

отчего же... можно вообще ничего не документировать - знаю массу примеров, когда так и делается.
так же по многим из примеров знаю к каким последствиям (и для разработчиков) это привело.

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

276

Обучение / Re: Бизнес-аналитик - полный курс подготовки. Где?

« : 19 Октября 2010, 19:39:57 »

2 spasatel:
IMHO бизнес-информатика - то, что надо. бизнес-аналитика и ищите, скажете, что учитесь и опыта нет, не в деньгах счастье, и ездить в их тьмутаракань вам очень даже удобно и т.п.
ищите сейчас, наработаете опыт, потом вопросов не будет.

277

Обсуждение статей / Re: Статья "Методы и средства программной инженерии при проектировании ИИС"

« : 19 Октября 2010, 12:06:30 »

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

278

Обсуждение статей / Re: Статья "Методы и средства программной инженерии при проектировании ИИС"

« : 19 Октября 2010, 11:26:17 »

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

P.S. вообще-то разумнее было бы послать в какое-нибудь издание (правильно, где платят больше (с))

279

Обсуждение статей / Re: Статья "Методы и средства программной инженерии при проектировании ИИС"

« : 19 Октября 2010, 11:20:04 »

один вопрос: а должны применяться какие ОСОБЫЕ методы и средства?

280

Проектирование / Re: Можно ли вообще спроектировать и реализовать систему без архитектуры?

« : 18 Октября 2010, 11:51:38 »

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

281

Конференции Семинары и Тренинги / Re: Управление изменениями требований: подготовка к семинару

« : 17 Октября 2010, 17:04:00 »

"спросить вопрос" - оригинально :о)))

NP

282

Варианты Использования (Use Case) / Re: Можно ли достичь нужной гибкости ПО?

« : 14 Октября 2010, 18:00:38 »

О! новая тема. это гуд.

правда я бы предложил назвать ее "насколько ПО должно быть близко к реальности" :о))) а то скатимся на ошибки и работу с ними (хотя это тоже важная и интересная тема). Т.е. нужно ли и до какой степени ПО должно приближаться к жизни - как-то так...

283

Варианты Использования (Use Case) / Можно ли достичь нужной гибкости ПО?

« : 14 Октября 2010, 14:36:19 »

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

284

Варианты Использования (Use Case) / Можно ли достичь нужной гибкости ПО?

« : 14 Октября 2010, 11:01:16 »

ну а ЧЕЛОВЕКА нужно просто учить, чтобы он был предусмотрительным, предвидел и учитывал "всевозможные ситуации"
и конкретные проектные решения, которые он принимает в конкретный момент, были гибкими.

285

Варианты Использования (Use Case) / Можно ли достичь нужной гибкости ПО?

« : 14 Октября 2010, 10:59:09 »

пост вообще-то к теме не относится. было бы разумно вынести в новую тему.

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