76

Проектирование / Re: Вопросы практики проектирования Web-приложения

« : 17 Апреля 2007, 13:03:21 »

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

Ваш вопрос архитектурный. И тут все проще чем кажется - нужно просто познакомится с существующими технологиями и тогда этот вопрос отпадет. Почему я об этом так говорю? Да просто потому что занимался писанием десктопных приложений на Delphi последние несколько лет. А потом надоело и решил посмотреть на Web. И тут даже с оглядкой даже на обилие языков и фреймворков стало понятно довольно быстро. Уже через месяц я сделал первое приложение на JavaServer Faces. И мне было несложно - пара хороших книг по фреймворку, большое количество примеров. Ну и в "мейнстримовских" ASP.NET и JSF это тот же визуальный дизайн и MVC2. Самый мейнстримовский - рельсы для руби.

Т.е. фреймворки сами предлагают архитектуру. Это быстрый способ построить приложение по готовой проверенной архитектурной схеме. И можно подобрать фреймворк подходящий под конкретные нужды.

Худшие предположения подтвердились, "как далеки они от народа". Твоя отчасти неправота раскроется, когда заказчик спросит: "Надо ли нанимать Java-программиста, или Вы сами на Delphi справитесь?". Т.е. КАКИЕ ТРЕБОВАНИЯ ЗАВИСЯТ ОТ ВЫБРАННОЙ СРЕДЫ ПРОГРАММИРОВАНИЯ И ЦЕНЫ В СВЯЗИ С ЭТИМ.

это просто не аналитика работа - архитектора ... но сравнение стоимости решения ... это гадание скорее - нужно идти со своими потребностями к проверенному подрядчику и спрашивать сколько это будет стоить

77

Обучение / Re: Опыт преподавания объектно-ориентированного подхода в моделировании, анализе etc

« : 17 Апреля 2007, 12:45:18 »

Можно немного не по ИТ? Я на прошлой неделе встречался с товарищем, научным сотрудником, работающим в сфере ЭРД (забыл точное определение Э а дальше реактивные двигатели). И он мне рассказал свою историю.

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

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

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

78

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

« : 17 Апреля 2007, 12:26:47 »

К сожалению,  я не пока знаю ответов на все эти вопросы ... я конечно строю свои догадки, но пока это только догадки. Просто объявили, что участвую в проекте, но даже стартового совещания пока небыло. И я копаю туда пока просто из-за наличия времени. Поэтому "типовая анкета" наверное бы устроила на этом этапе.

79

Управление Проектом / Re: Планирование софтверного проекта: Источ&#

« : 17 Апреля 2007, 11:47:46 »

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

Ну и конечно для слишком неопределенных проектов, толковый WBS можно построить только на самое ближайшее будущее, типа месячной итерации. И это опять же недостаточная определенность цели. Чем точнее цель - тем легче.

Как писал известный автор "каждому проекту своя методология", видимо и подход с WBS и источниками где-то на том же уровне

80

Управление Проектом / Re: Планирование софтверного проекта: Источник WBS?

« : 17 Апреля 2007, 11:39:55 »

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

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

Т.е. WBS это план достижения результата. Пока результат планируется как "создать эффективную систему" нужно перевести "эффективность" в набор целей. И опять же таки, для проектов с большой степенью неопределенности, на взгляд гибких методологий, можно ответить только адаптивным планированием. Т.е. поскольку это цели заказчика, то пусть он их нормально сформулирует и переведет в понятные разработчикам образы. Когда заказчик не знает чего он хочет, его потихоньку итеративно раскручивают.

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

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

И вот как же агли в стартапах применяется без бизнесмена лидера ... это вопрос.

Вальсируя с медведями
"В начале, на заре ИТ-индустрии, обоснование для создания новых продуктов было очень простым. Системы, которые тогда устанавливали, обычно заменяли ручной труд клерков. Экономия трудозатрат и была мерилом выгоды, а затраты на разработку системы – издержками.

Времена изменились. Большая часть обеспечивающих прямую экономию систем построена давным-давно. Сегодня вместо создания систем, компенсирующих затраты, чаще осуществляются проекты, направленные на улучшение позиции компании на рынке. Такие системы гораздо труднее обосновать. «Нам это необходимо» или «Эта система нам нужна, чтобы сохранить конкурентоспособность».

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

81

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

« : 16 Апреля 2007, 18:47:27 »

Здравствуйте, uml2.ru!

Не поделится ли кто соображениями про структуру анкеты для потенциального пользователя. Я http://nvoynov.blogspot.com/2007/04/blog-post_7484.html немножко рассказал про проблему и http://nvoynov.googlepages.com/interview.pdf ободрал на память структуру интервью из "Принципы работы с требованиями" Леффингуэлл, Уидриг

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

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

82

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

« : 16 Апреля 2007, 14:39:20 »

Спасибо - на первый взгляд интересно. Обязательно посмотрю внимательнее.

83

Управление Проектом / Re: Планирование софтверного проекта: Источник WBS?

« : 16 Апреля 2007, 14:34:26 »

Если занимаешься постоянно решением похожих проблем (некоторой определенной работой, типа разработки ПО, разработки сайтов), значит можешь выделить основные шаги решения проблемы. Т.е. идентифицировать задачи, которые нужно выполнить для достижения цели. Это и есть WBS. Как говорит Ф.О'Коннел "всегда есть последовательность событий".
С постановкой здачи чесно говоря не понял ... это должно быть включено - все работы по проекту, другое дело, что некоторых участников может не интересовать некоторая часть работ по проекту, например зачем разработчику знать про маркетинг

Фраза из серии "Делайте то, что нужно делать, а то, что не нужно делать - не делайте".
Как учесть все работы? Откуда эти работы брать? Что понимается под формлировкой "постановка задачи"?
"Опускаются маркетинговые работы, подготовка технической инфраструктуры, часто опущено обучение, малое внимание уделяется обеспечению эффективности работы системы. На мой взгляд, это следствие отсутствия целостного, интегрированного подхода к планированию "из одной точки"."

У меня есть друг, который занимается научными проектами - работает в теме ЭРД. Он постоянно мониторит рынок проектов по своей тематике ищет работы на стороне. Одним из критериев подбора проекта является именно составление WBS. Он говорит, что берется за проект только в том случае, когда он приблизительно знает как за это взяться, какие шаги нужно предпринять для его выполнения.

84

Управление Проектом / Re: Планирование софтверного проекта: Источник WBS?

« : 14 Апреля 2007, 01:53:23 »

WBS он и есть WBS - структура работ по проекту. И составляется он так чтобы учесть все работы которые нужно выполнить от постановки задачи до поставки результата. Чем точнее и мельче его написать тем легче будет управлять и отслеживать. В идеале задачи с продолжительностью в 1 день.

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

Т.е. это просто карта помощь. Для создания сайтов наверное тоже есть типовые WBS - попробуй посмотреть в MS Project.

85

Книги, статьи и ресурсы / Re: Книги: Крэг Ларман. Применение UML и шаблонов проектирования

« : 14 Апреля 2007, 01:37:30 »

В пору к ней можно настоятельно порекомендовать Мартина "Быстрая разработка программ" .. на уровне принципов ООП-проектирования шаблонов и хороших примеров... Но все это скорее не UML а просто хорошие практики создания правильного ОО ПО.

86

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

« : 14 Апреля 2007, 01:34:16 »

На мой взгляд intuit отличный ресурс для быстрого старта и не более - сам прошел несколько курсов и в принципе доволен. Немного не современный и иногда просто отвратительный (описание что такое БД в курсе DataMinig).
Сказывается наверное что пишут курсы типичные преподаватели в соответствии с типичными учебными планами своих ВУЗов.

87

Проектирование / Re: Книги: Лешек Мацяшек - Анализ требований и проектирования систем. Разработка информационных сист

« : 14 Апреля 2007, 01:29:11 »

Мне не понравилась. Точно сформулировать почему не могу. Просто пролапатил как-то кучу книг и уже смешались кони/люди. Лежит просто на полу - выбросить жалко, т.к. деньги плачены. Отдам экземпляр бесплатно в Киеве.
Да и объем не позволяет качественно рассмотреть все представленные вопросы. Т.е. не дотягивает - так некрепкий середнячок для студентов.

88

Сообщество Аналитиков / Re: Система рекомендаций профлитературы: Постановка задачи

« : 14 Апреля 2007, 01:12:42 »

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

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

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

89

Сообщество Аналитиков / Re: Рецензии на книги

« : 14 Апреля 2007, 01:01:27 »

Можно спросить, какой вид должна иметь рекомендация? Просто мнение о книге? Как его составить если она еще не вышла