151

Для всех / Re: Методы системного анализа

« : 01 Декабря 2009, 16:04:40 »

Спасибо.

А можете еще какие нибудь материалы порекомендовать?

В том, на что bas дал ссылки, столько материалов упоминается, что примерно на пару лет изучения хватит.

152

Примеры / Re: Удивительный контрпример неприменимости как ООП так и Relation Database.

« : 30 Ноября 2009, 13:09:51 »

Кто может сказать, что тут обсуждали?

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

153

Примеры / Re: Удивительный контрпример неприменимости как ООП так и Relation Database.

« : 30 Ноября 2009, 12:14:55 »

Господа, не переживайте, по моему опыту общения с милицией по поводу украденных вещей, вопрос идентификации неразличимо похожих предметов (если это, конечно, не что-то типа картины Ван-Гога или скрипки Страдивари), никого сильно не волнует.
Диалог примерно такой:
"Это ваша шапка?"
"Очень похожа, но тут еще 999 таких же шапок".
"У вашей шапки есть какие-то особыве приметы?"
"Не припомню."
"Так, забирай любую, какая нравится, они все тут одинаковые, распишись только в получении именно своей шапки".

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

154

Термины и Определения / Re: [Термин] FEATURE

« : 30 Ноября 2009, 11:33:52 »

Фича, это то, за что цениться эта система ее потребителями

Это добрые фичи. А есть еще злые фичи, те самые, которые "Это не баг, это фича"
С учетом этой языковой традиции русскоязычных разработчиков, фича в русском языке - это скорее артефакт программы, а не требование. То есть это не совсем то, что feature. ИМХО.

155

Примеры / Re: Маг. диссертация: Электронные архивы в ВУЗах

« : 21 Ноября 2009, 13:29:46 »

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

Это хорошо, но имейте в виду, что если нормативные документы регламентирую сроки хранения больше 5 лет, то электронные архивы не обеспечивают сохранности. Бумага хранится сотни лет, электронные копии проблематично прочитать через 10-15 лет.
Поэтому нужно обеспечивать регламентировнные архивные процедуры по бумаге, и иметь привязку электронных копий к ссылкам  на места хранения оригиналов.
Правда, для студенческих работ вряд ли нужно более 5 лет обеспечивать.

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

Все перечисленные свойства стандартны для всех систем ЭА. Или вы думаете, что ваша кафедра сталкивается с уникальными задачами по хранению документов, которые больше ни перед кем в мире не возникают

На конкретные вопросы постараюсь ответить.

156

Примеры / Re: Маг. диссертация: Электронные архивы в ВУЗах

« : 20 Ноября 2009, 23:26:53 »

Целью работы является исследование проблемы создания  электронных архивов в ВУЗах; исследование и сравнительный анализ подходящих решений; проектирование и создание электронного архива и системы управления этим архивом для кафедры.

InsomniA:
Я занимался несколько лет эл архивами, поэтому могу вам подсказать некоторые направления, в которых можно копать.

1. Основной проблемой создания ЭА в ВУЗах, как и и везде, впрочем, является финансирование наполнения архива (сканирование, распознавание, атрибутирование ) и последующего поддержания его в актуальном состоянии. 90% таких проектов проваливаются именно по этой причине.

2. СУществуют сотни готовых решений, в.т.ч. бесплатных (преимущественно университетских). Как вы понимаете, эта задача почти так же распространена, как и ERP, поэтому многое стандартизировано, в.т.ч. форматы обмена. Не изобретайте велосипед. Ищите по словам Library Management System.

3.ПРи проектировании системы архива не забудьте, что в систему входят также люди и процедуры. По регламентации процедур ищите по словам Record MAnagement, а нашу русскую специфику - рекомендации ВНИИДАД.

157

Идеи и мозговой штурм / Re: Методы оценки эффективности Аналитика

« : 18 Ноября 2009, 17:51:34 »

А как вам такой случай - заказчик пустил аналитиков только на один из своих объектов...
Что имеем в итоге - по закону подлости это оказался единственный объект, в котором отсутствовал важный элемент бизнеса. В итоге получили серьезную проблему и МНОГО запросов на изменение.

Для аналитика это из разряда "Бывает"... Самый ловкий спецназовец может попасть под шальную бомбу. Надо набирать статистику по работе аналитика по разным проектам,с учетом их сложности.
 А по данному случаю это недоработка ПМа - он должен был после отказа пустить на другие объекты заставить закзачика подписать бумагу, что если на других объектах обнаружатся дополнительные  требования, то это будет расширение рамок договора и, следовательно, доп. соглашение по деньгам.

158

Идеи и мозговой штурм / Re: Методы оценки эффективности Аналитика

« : 18 Ноября 2009, 12:48:23 »

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

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

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

159

Идеи и мозговой штурм / Re: Методы оценки эффективности Аналитика

« : 18 Ноября 2009, 01:06:58 »

У нас эффективность оценивается путем подсчета заявок на доработку того или иного функционала. То есть если аналитик отработал хорошо, то функционал практически не дорабатывается первые три четыре месяца. Если анализ был проведен неверно, то как правило возникает большое колличество доработок.

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

160

Теория моделирования и нотации / Re: Явная связь класса с прецедентом - бред?

« : 07 Ноября 2009, 15:07:54 »

Поэтому UseCase-диаграмма и Class-диаграмма практически "параллельны" друг-другу. Рисунок во вложении.

К меня создалось впечатление, что Вы неправильно используете Use Case'ы.
Вы по каким источникам изучали UML?

161

Работа / Re: Знание английского языка

« : 05 Ноября 2009, 14:50:03 »

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

162

Теория моделирования и нотации / Re: Явная связь класса с прецедентом - бред?

« : 05 Ноября 2009, 14:44:10 »

Разве не естественно, если необходимость конкретного класса вытекает из существования конкретного прецедента?

Нет, из существования прецедента не вытекает необходимость создания конкретного класса. Любой прецедент можно реализовать многими разными наборами классов, их придумывание как раз и составляет процесс разработки архитектуры системы. Грубо говоря, реализации прецедента "пользователь садится в безлошадную повозку и едет в пункт назначения" не требует использования класса "Двигатель внутреннего сгорания". Это может быть и класс "электрический двигатель". Но когда вы выбрали класс ДВС для работы в составе системы, имеет смысл поставить трассировку от него на прецедент, чтобы потом, когда очередной разработчик предложит вместо ДВС использовать лошадь, можно было по трассировке быстро найти причину, почему лошадь нельзя.

163

Реализация / Re: Создание технической документации для ПО

« : 05 Ноября 2009, 03:58:23 »

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

ПС. Наверное, это никак не стыкуется с концепцией Agile...

164

Работа / Re: Знание английского языка

« : 03 Ноября 2009, 20:10:45 »

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

165

Работа / Re: Знание английского языка

« : 03 Ноября 2009, 12:48:00 »

Для ИТ-шника знание  языка хотя бы на техническом уровне жизненно необходимо, хотя бы для получения информации из первоисточника, в неискаженном виде.

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