496

Варианты Использования (Use Case) / Re: Ссылка на алгоритмы при написании вариантов использования

« : 16 Октября 2009, 10:36:35 »

1. ... Но любая ИС по определению должна обеспечить ввод, изменение и удаление и т.п. просмотр..

Что-то новое в определении ИС :о)) ИС вроде должна решать какие-то предметные задачи, нее?
Вот именно из-за подобных определений люди и пишут подобные названия ВИ. Это неправильно.

Чем именно плохи мои название ВИ? Не отражает бизнес-смысл операции? "ВИ1. учесть поступление деталей", "ВИ2. учесть расход деталей" ?

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

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

497

Книги, статьи и ресурсы / Re: Посоветуйте хорошие книги(у)

« : 14 Октября 2009, 12:13:35 »

может стоит в издательство обратиться?..

498

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

« : 09 Октября 2009, 13:06:23 »

Каждая новая система нова только максимум на 5%. Чтобы написать на нее ТЗ надо досконально знать остальные 95%. А на 100% новую систему именно в принципе нельзя создать. Иначе почему бы было не начать создавать OLAP системы на следующий день после ввода в эксплуатацию ЭВМ ENIAC в 1946 году?

Может быть такая аналогия поможет: представьте себе человека, пишущего ТЗ на текстовый редактор, и никогда не работавший с MS Word или его функциональными аналогами, только с Notepad. Представили себе это ТЗ?
Чтобы что-то требовать, надо знать достигнутые на сегодня горизонты, и понимать, какие проблемы возникают у пользователя именно на этом горизонте.

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

499

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

« : 08 Октября 2009, 19:44:25 »

Вряд ли можно написать ТЗ, не имея личного опыта работы с OLAP в конкретных практических целях.

тут Вы неправы, иначе бы ни одной системы нельзя было бы создать в принципе, опыта работы с отсутствующей системой-то тоже не было бы :о))

500

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

« : 08 Октября 2009, 13:03:20 »

Раз задача для Вас новая, возможно Вы некорректно ее формулируете. Что значит для Вас "разработка OLAP-отчета"?

Вам нужно отдельный отчет разработать в имеющейся OLAP-системе? или саму OLAP-систему?
Хранилище есть? Там есть первичные данные для Вашего отчета? или Вам нужно эти данные еще и собрать? (впрочем коллеги об этом уже спросили).

P.S. В качестве простейшего и одного из доступных OLAP-средств посмотрите сводные таблицы (pivot table) Excel. Если у Вас есть хранилище, то можно попробовать смоделировать Ваш отчет в нем. Так Вы лучше поймете, что должно быть в ТЗ с предметной точки зрения.


 

501

Проектирование / Re: Проектирование схемы взаимодействия подразделений

« : 08 Октября 2009, 11:41:06 »

по запросу 'все подразделения, которые "взаимодействуют" друг с другом' отберется только половина подразделений

ну это как запрос написать...
если руками, то проблем не будет :о))

502

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

« : 05 Октября 2009, 16:19:20 »

даже если его должность - программист, и он обладает соответствующей квалификацией, с точки зрения системы он всё равно будет ПОЛЬЗОВАТЕЛЕМ, как бы это ни было унизительно для него :о))

503

Проектирование / Re: Проектирование схемы взаимодействия подразделений

« : 05 Октября 2009, 16:16:39 »

Нужно спроектировать БД, поэтому нужна ER диаграмма.
Выяснилось что понятие «Взаимодействует» не единственное вид связи между объектами. Возможны и другие виды связи подразделений: «Подчиняется», «Руководит», «Оценивает», «Оценивается», «Контролирует», «Контролируется» и др. парные значения.
Вот как бы это выразить в ER диаграмме?

в формате ER-диаграммы нет таких видов соотношений :о)) пользуйтесь поведенческими диаграммами, предварительно ответив на вопрос: что значит "руководит" и прочее?

504

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

« : 05 Октября 2009, 12:40:25 »

и что, пользователь теперь должен документацию писать чтоли, как в соседней теме?

505

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

« : 05 Октября 2009, 11:01:30 »

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

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

IMHO  нужно документировать классы/методы в процессе проектирования, чтобы программист получал готовую спецификацию и только исполнял ее в соответствии с определенными нормативами по времени. Таким образом документация будет создаваться по мере продвижения разработки ДО того, как что-то будет закодировано. Ну а программист станет, наконец, обычным кодером и займет свое положенное место в пищевой цепочке.

Ничего личного.

506

Консалтинг и Внедрение / Re: Документы при приемке ПО

« : 05 Октября 2009, 10:46:25 »

Какой перечень документов получает заказчик от компании подрядчика на внедряемую систему?
Меня интересует перечень документов и их примерное содержание(по госту и тп).

ГОСТ носит рекомендательный характер, его наличием никого не убедишь. Они Вам в ответ сразу скажут, что они работают по наиновейшим технологическим методологиям (super-extra-UMgile-concurrent-extreme-development), где требования ГОСТ по документированию не являются обязательными. И вообще это экспериментальный софт, НИОКР какой-нибудь, чего же Вы еще от нас хотите.
Думайте в направлении: Что является обязанностью поставщика по договору? Он ее выполнил?

Из доков что есть: руководство пользователя и все.
Доступ к базе данных есть только у них.Мы можем только юзать и потребовать доработать то-то или что-то.

А как формальными документами регламентируется право их доступа к Вашей базе? Или все не так и Вы у них право использования их БД приобрели? Или они Вам еще и услуги по управлению базой оказывают?

Поясните ситуацию.

Пару дней назад общались с представителями ихней компании, попросили описание субд.
На что они очень нервно отреагировали,сказали:"Надо подумать.Надо еще убедиться в компетенции ваших спецов"

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

Поэтому руководство ... создать документацию о системе.
А мне интересен выше указанный вопрос.
И вообще реально что-то у них вытащить?

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

Наша компания чтит: ITIL ,ISO9000.
Суть в том. Если их (поставщиков) компания рухнет ,то нам конец.

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

Кстати, Вам еще не конец. Этот риск нужно правильно обработать, разумеется, потратив некоторое немеряное количество денег. Самое время поставить вопрос об обеспечении снижения зависимости от поставщика. Я бы попытался играть на двух фронтах в этой ситуации: пытался бы договориться о документации, и начал бы дёргаться на тему приобретения/разработки аналогичного софта в другой более квалифицированной компании.

507

Для всех / Re: Контроль доступа и учёт рабочего времени

« : 02 Октября 2009, 13:21:54 »

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

ну нет у них столько денег сразу, пусть тратят гораздо больше частями... какие проблемы? топикстартер тут причем? ей сказали - она делает...

508

Проектирование / Re: Проектирование схемы взаимодействия подразделений

« : 01 Октября 2009, 13:00:35 »

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

На организационном уровне должен быть определен предмет взаимодействия - конкретный частный случай: процесс/процедура, в котором задействованы оба подразделения, или документ, который передается из подразделения в подразделение.

509

Варианты Использования (Use Case) / Re: Многозвенная архитектура - как рисовать много Use-cases?

« : 01 Октября 2009, 11:08:55 »

2 leinsoo:
Два вопроса:
во-первых, я бы хотел-таки послушать начальника транспортного цеха топикстартера
во-вторых, я не понял, Вам тоже совет нужен или нет? Для совета мало данных, впрочем, Вы, похоже, сами справляетесь со своими переделками.

по остальным вопросам не вижу предмета для обсуждения

510

Варианты Использования (Use Case) / Re: Многозвенная архитектура - как рисовать много Use-cases?

« : 30 Сентября 2009, 11:21:08 »

На днях пришлось воспользоваться лет 5 назад разработанным редактором символов для ГИС.

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

Для пояснения. Книжка с кратким перечнем символов и описанием основных правил их отображения занимает 520стр (в новой редакции). Почти половина символов имеет особенности в отображении, формировании подписи, при наложениях, при групповом и одиночном применении, изменение масштаба, полилинии, сплайны и тд. и т.п. Вариант использования с названием "создание символа для отображения объекта на картфоне" явная профанация.

Разрабатывали 2 человека 2 года (не только редактор, его они из-за лени написали). А. Шемис - передай им привет, их систему вчера Медведеву показывали.

1. я не очень большой специалист по ГИС, и пока не планирую развиваться в этом направлении, поэтому ничего об этом сказать не могу, даже если Медведеву она понравилась. (в сторону: интересно, что он в ней понял?)
2. с таким же успехом можно привести в качестве примера сложности интерфейса CAD-системы, Photoshop, Corel, Word, наконец, или что-нибудь подобное. но тем не менее сложный интерфейс не мешает работать и полезно использовать (!), т.е. получать нужный результат, даже не суперквалифицированному специалисту.
3. несмотря на то, что я видел неплохие системы разработанные нашими (отечественными) специалистами в подобном режиме, осмелюсь утверждать, что большинство доморощенных систем, созданных таким образом, обладают массой архитектурных проблем (а уж книги на 520 страниц, тем более в новой редакции, вообще в руки брать нельзя). возможно, Вы как раз пытаетесь их унаследовать. еще раз сошлюсь на пианино (пока еще ни одна система не приблизилась к нему) - клавиш всего ничего по большому счету, а сыграть специалист может бесконечно много... это один из примеров хорошей архитектуры.
4. отвлекитесь и посмотрите на свою систему не с точки зрения операций, а с точки зрения целей, что она по большому счету делает. Вот это и будет первым шагом для правильного разбиения на группы и формулирование use case.

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