Редко я встречал проекты, в которых конечный продукт соответствовал ТЗ на 100%. Если, конечно ТЗ писал не сам исполнитель, и в таком виде, что ему может соответствовать, что угодно, за ради прикрытия задницы :-)
Системный архитекторы - вообще забавные люди - бывают двух типов:
1) Теоретик - пишет что и как писать и никто так не делает; Часто встречается в ИТ отделах не ИТ компания (заводов например)
2) Царь и бог - что-то придумал, что-то написал. Все остальные пишут UI и вспомогательные функции как могут, а точнее как получится. Потому как "богу" не до UI и мелочи всякой! Получается дикий, необузданный монстр с афигенной архитектурой - этакий цифровой Франкенштейн! :-)
А оно надо? Вот к примеру проект рассчитанный на два года реализации. Первый этап - через два месяца создать версию с минимальным функционалом и запустить в эксплуатацию. Далее еще через два месяц надо вторую версию с расширенным функционалом. Еще через два с нагрузкой на 10000 одновременных активных пользователей и так далее.
Что мы делаем в соответствии с описанной методой:
- мы проектируем систему с учетом всех возможных расширений - два месяца
- разрабатываем ядро системы с учетом возможностей его расширения и повышения производительности за счет масштабирования аппаратных средств - два месяца минимум, а то и пол года (какую спецификацию написать :-) )
- разрабатываем минимальный функционал, закупаем оборудование, устанавливаем - два месяца (опять таки минимум)
Получилось странное! Прошло пол года - а у нас классная штука с ядром и чем-то по спецификации. Заказчик уже 4 месяца ждет первой версии чтобы ее раскручивать по всякому. А у нас понимаешь ли спецификации и жесткая архитектура.
Не всегда методика описанная автором статьи соответствует реальности. Не спорю - проектировать и планировать надо. Но не обязательно так и в такой последовательности. Вариантов много и для каждого проекта нужно подбирать наиболее подходящий.
Варианта два: либо подскажут "старики",
либо программист разберется в коде сам - ели он конечно профессионал.
Если не профессионал, и некому объяснить - гиблое дело, такому никакая документация не поможет. Программист должен уметь читать код, как чужой так и свой. И кроме того грамотно его писать. Если функция размером в 40 экранов - тут какую хочешь документацию пиши - все одно - хрен разберешь.
И кстати, OpenSource проекты, часто там документация? Максимум на API - и то когда это библиотека :-) Народу же с этим кодом работает гораздо больше, чем с напрочь задокументированными системами. И ничего - не жужжат! :-)
Что-то я не совсем понял, а чем ситуация с вниманием потребителя в интернете отличается от того же внимания на улице?
Там тоже вешают большие баннеры в пол дома. Подбирают по потребностям месторасположения объектов. Например на трассах: шиномонтаж, запчасти, кафешки, мотели, проститутки. В гипермаркетах тысячи продуктов сгруппированы и разложены по определенной последовательности, в соответствии с предполагаемым движением посетителя и ценой. Учитывается куда человек посомотрит и на что обратит внимание в первую очередь. В магазин с едой продают кастрюли, вилки, ножи, мангалы, уголь, журналы. Стараются учитывать все.
И заметьте, никто у посетителя не спрашивает что его больше интересует - арбузы, водка, или журналы. Или вообще, он просто за хлебом пришел.
А может занять и 50 и 100% времени - и потом получится что те мелочи которы проработали сразу - совсем не такие - потому как технически сложно реализовать, и видение у заказчика поменялось, и вообще мир не стоит на месте :-) Как-то не экономно получается... Не аккуратненько :-)
Кончено нельзя - а то целей для разработчиков не будет. Только планировать надо как можно чаще - иначе план свою актуальность потеряет. И сам процесс должен занимать как можно меньше времени. В плане должно быть написано столько - сколько нужно программисту для понимания и не строчкой больше. А как реализовать мы сами знаем :-)
А я идеи записываю с целью структуризации информации в мозге! В своем. Потом как правило эта бумажка не нужна. Она и так в голове есть. :-) Потом пищу другую бумажку для разработчиков - в которой описывается по сути что должно получится в общем.
Я бы сказал - людей лучше подталкивать к изучению методологий разработки и их применению. А то что Вы предлагаете - это выдранные из контекста практики. И почему-то Вы выбрали только один из возможных вариантов их использования. Никто не говорит что не надо проектировать, планировать, и тестировать.
Например само по себе тестирование - очень полезная вещь и тестировать можно без предварительного проектирования по стандартам как вы описывали.
Надо Вам написать функцию сложения двух чисел? Сначала пишешь тест, в котором проверяется работы этой функции. По сути просто вызываем функцию с двумя параметрами и сравниваем с верным показателем. Тоько после этого пишем код самой функции. Чем не тестирование перед проектированием - даже круче - перед кодированием.
Почему проектировать систему сразу не по ходу реализации ее функций. Зачем писать документацию на систему - если она нужна только ее разработчикам. А разработчик и так ее знают как свои пять пальцев - потому что сами же и написали. Вот другая точка зрения.
Есть разные методологии. И я не говорю о том что проектировать не нужно - просто это можно делать по разному, как это делать определятся в каждом конкретном случае.
Тоже вариант, но все равно всего не предусмотришь - а время можно потерять достаточно!
Может требования лучше уточнять в процессе разработки - а на начальном этапе хватит метафоры и плана на первые один-два месяца разработки.
Про методологии разработки программного обеспечения написано достаточно. И спору нет их надо знать. Но не всегда все так как пишет автор статьи. Не всегда известны функциональные требования к системе на 100% в начале проекта.
Не всегда плохо переписать ядро 15 раз. И даже лучше писать ПО чтобы можно было его переписывать. И желательно частями, а не целиком сразу - когда архитектура изначально четко заложена.
Когда разрабатываешь ядерную боеголовку и ПО для нее - тогда нужно 100% следование стандартам и обширная предпроектная подготовка.
Если же ПО само по себе динамическое, и может меняется со временем в зависимости от растущих потребностей пользователей - тогда и подходы должны быть более гибкими. Но в целом я с автором согласен - проектировать надо, но может не всегда по схеме им предложенной. Гибкость подхода нужно применять товарищи!
В наши дни дети уже не видят разницы между заслуживающими доверия новостями от объективных профессиональных журналистов и теми писульками
Однако да! Объективные источники, точно! У нас в провинции наши источники покупаются администрацией авансом на год за несущественные суммы. Это достоверный факт, у них даже есть официальный договор. Представляю себе реакцию заказчика (администрации) если бы про них не лестно отзывались. Они даже, когда люди в прямом эфире что-то про них говорят, телефонные трубки обрывают, заставляют из эфира убирать. Кака тут нахрен объективность...
Элита, блин! Кто-то сказал. сейчас не вспомню: "Политики, уж поверьте, решают не наши с Вами проблемы, а свои".
По моему уже давно есть конструкторы автомобилей. И даже вертолетов и самолетов. Вот покупаешь такой и собираешь у себя в гараже. Правда не скажу, доступны ли для общего пользования чертежи и инструкции.
И вообще, идея не нова. Еще в советское время существовали такие журналы как "Радио", "Моделист конструктор", и по моему сейчас существует. Чем не open-source.
Да, изъятие правомерно в случае если у следователя (начальника отдела) возникают подозрения. Кстати, они приходят с понятыми, которые за все расписываются. Например: есть подозрение в использовании нелицензионного Windows, понятые расписались, компы забрали на экспертизу.
Вообще, лучше чтобы не брали. Если у вас Linux, говорите что это свободно-распространяемое ПО, под лицензией GPL. Ни в коем случае не говорите что лицензии вообще нет, все списываете на GPL, и показывайте ее текст. Если на Linux стоит графическая оболочка, показываете им ссылки на GPL лицензию в меню "О программе". Если и это не помогает, не в коем случае не сопротивляетесь, а то еще и в кутузку заберут. И главное, когда будет состарятся протокол, указать все, и про Linux и про GPL и что милиция ваши доводы не приняла во внимание.
И еще, имеет смысл, когда они придут, позвонить в службу внутренней безопасности ментовки, прям при них, и выяснить правомерно они ходят или нет? Говорят, они тогда осторожнее вести себя начинают. Но, правда я не пробовал.
На счет мер, ничего сказать не могу. Скорее всего, как у нас бывает никаких мер к нему принимать не будут, потому как расписался сам начальник отдела и понятые - значит подозрение возникло. А экспертиза показала обратное. но что поделать - сложный случай. сразу и не разобрались :)
После того, как была проверка у нас - занялся этим вопросом. Книжку купил "Досмотр и обыск". Там вычитал, что обыск офисов могут проводить без санкции суда или прокурора, для этого требуется подпись следователя на постановлении или какого нибудь другого мента - короче того кто ответственный за данное мероприятие . В нашем случае подписался начальник отдела милиции.
Если дома скачал, то может и не посадят. А вот если на работе нашли коллекцию - могут посадить директора или админа. Типа, использование в коммерческих целях. Знакомому уже дали год условно. за использование пиратского ПО, и еще на нескольких уголовное дело завели. Когда ко мне в офис приходили, искали все. Все каталоги прошарили, файлы искали с нужными расширениями. На doc и xls приходилось объяснять, что Open Office тоже умеет с такими файлами работать.
И вот еще, такое сообщение прошло на внутреннем форме одной компании:
"У нас в филиале в Нижнем Новгороде сегодня собака с милицией (С) забрала линуксовый сервер. С формулировкой - нет иконки "Мой компьютер", значить, не лицензионное. Вот так." :)
Каждый должен заниматься своим делом, мне так кажется. Программисты должны писать программы, руководители - руководить. Конечно, всесторонность развития и навыков это хорошо. Но добиться действительно хороших результатов распыляясь на все очень сложно. По идее, задачи должны ставить потенциальные пользователи ПО. В некторых случаях это руководители организаций. Как показывает практика, ПО разработанное на заказ профессионалами, при тесном общении с заказчиком работает более стабильно, удобнее в использовании и более четко отражает потребности, нежели разработанное непрофессионалами или профессионалами, у которых работа с клиентом прихрамывает.
Перевел контору на Gentoo. По началу непривычно было, сечас нормально. Все задачи, которые возникают - решаем без особых сложностей. Хочу заметить, не все в конторе даже windows смогут поставить. Были, кончено затыки, к примеру факсы принимать и получать. И еще по мелочи. Немного Open Office отличаются он привычного MS Office. Но есть один неоспоримый плюс - Free Soft. Когда к нам пришли менты с проверкой, это плюс покрыл все возможные минусы. Они даже удивились, когда мы сказали что у на Виндовсов нет... Чувствую вряд ли мы уже вернемся обратно к использованию коммерческого ПО. Если только для сильно специализированных целей.
Системный архитекторы - вообще забавные люди - бывают двух типов:
1) Теоретик - пишет что и как писать и никто так не делает; Часто встречается в ИТ отделах не ИТ компания (заводов например)
2) Царь и бог - что-то придумал, что-то написал. Все остальные пишут UI и вспомогательные функции как могут, а точнее как получится. Потому как "богу" не до UI и мелочи всякой! Получается дикий, необузданный монстр с афигенной архитектурой - этакий цифровой Франкенштейн! :-)
Что мы делаем в соответствии с описанной методой:
- мы проектируем систему с учетом всех возможных расширений - два месяца
- разрабатываем ядро системы с учетом возможностей его расширения и повышения производительности за счет масштабирования аппаратных средств - два месяца минимум, а то и пол года (какую спецификацию написать :-) )
- разрабатываем минимальный функционал, закупаем оборудование, устанавливаем - два месяца (опять таки минимум)
Получилось странное! Прошло пол года - а у нас классная штука с ядром и чем-то по спецификации. Заказчик уже 4 месяца ждет первой версии чтобы ее раскручивать по всякому. А у нас понимаешь ли спецификации и жесткая архитектура.
Не всегда методика описанная автором статьи соответствует реальности. Не спорю - проектировать и планировать надо. Но не обязательно так и в такой последовательности. Вариантов много и для каждого проекта нужно подбирать наиболее подходящий.
либо программист разберется в коде сам - ели он конечно профессионал.
Если не профессионал, и некому объяснить - гиблое дело, такому никакая документация не поможет. Программист должен уметь читать код, как чужой так и свой. И кроме того грамотно его писать. Если функция размером в 40 экранов - тут какую хочешь документацию пиши - все одно - хрен разберешь.
И кстати, OpenSource проекты, часто там документация? Максимум на API - и то когда это библиотека :-) Народу же с этим кодом работает гораздо больше, чем с напрочь задокументированными системами. И ничего - не жужжат! :-)
Там тоже вешают большие баннеры в пол дома. Подбирают по потребностям месторасположения объектов. Например на трассах: шиномонтаж, запчасти, кафешки, мотели, проститутки. В гипермаркетах тысячи продуктов сгруппированы и разложены по определенной последовательности, в соответствии с предполагаемым движением посетителя и ценой. Учитывается куда человек посомотрит и на что обратит внимание в первую очередь. В магазин с едой продают кастрюли, вилки, ножи, мангалы, уголь, журналы. Стараются учитывать все.
И заметьте, никто у посетителя не спрашивает что его больше интересует - арбузы, водка, или журналы. Или вообще, он просто за хлебом пришел.
Например само по себе тестирование - очень полезная вещь и тестировать можно без предварительного проектирования по стандартам как вы описывали.
Надо Вам написать функцию сложения двух чисел? Сначала пишешь тест, в котором проверяется работы этой функции. По сути просто вызываем функцию с двумя параметрами и сравниваем с верным показателем. Тоько после этого пишем код самой функции. Чем не тестирование перед проектированием - даже круче - перед кодированием.
Почему проектировать систему сразу не по ходу реализации ее функций. Зачем писать документацию на систему - если она нужна только ее разработчикам. А разработчик и так ее знают как свои пять пальцев - потому что сами же и написали. Вот другая точка зрения.
Есть разные методологии. И я не говорю о том что проектировать не нужно - просто это можно делать по разному, как это делать определятся в каждом конкретном случае.
Может требования лучше уточнять в процессе разработки - а на начальном этапе хватит метафоры и плана на первые один-два месяца разработки.
Не всегда плохо переписать ядро 15 раз. И даже лучше писать ПО чтобы можно было его переписывать. И желательно частями, а не целиком сразу - когда архитектура изначально четко заложена.
Когда разрабатываешь ядерную боеголовку и ПО для нее - тогда нужно 100% следование стандартам и обширная предпроектная подготовка.
Если же ПО само по себе динамическое, и может меняется со временем в зависимости от растущих потребностей пользователей - тогда и подходы должны быть более гибкими. Но в целом я с автором согласен - проектировать надо, но может не всегда по схеме им предложенной. Гибкость подхода нужно применять товарищи!
Однако да! Объективные источники, точно! У нас в провинции наши источники покупаются администрацией авансом на год за несущественные суммы. Это достоверный факт, у них даже есть официальный договор. Представляю себе реакцию заказчика (администрации) если бы про них не лестно отзывались. Они даже, когда люди в прямом эфире что-то про них говорят, телефонные трубки обрывают, заставляют из эфира убирать. Кака тут нахрен объективность...
Элита, блин! Кто-то сказал. сейчас не вспомню: "Политики, уж поверьте, решают не наши с Вами проблемы, а свои".
И вообще, идея не нова. Еще в советское время существовали такие журналы как "Радио", "Моделист конструктор", и по моему сейчас существует. Чем не open-source.
По моему - чисто маркетинг.
Вообще, лучше чтобы не брали. Если у вас Linux, говорите что это свободно-распространяемое ПО, под лицензией GPL. Ни в коем случае не говорите что лицензии вообще нет, все списываете на GPL, и показывайте ее текст. Если на Linux стоит графическая оболочка, показываете им ссылки на GPL лицензию в меню "О программе". Если и это не помогает, не в коем случае не сопротивляетесь, а то еще и в кутузку заберут. И главное, когда будет состарятся протокол, указать все, и про Linux и про GPL и что милиция ваши доводы не приняла во внимание.
И еще, имеет смысл, когда они придут, позвонить в службу внутренней безопасности ментовки, прям при них, и выяснить правомерно они ходят или нет? Говорят, они тогда осторожнее вести себя начинают. Но, правда я не пробовал.
На счет мер, ничего сказать не могу. Скорее всего, как у нас бывает никаких мер к нему принимать не будут, потому как расписался сам начальник отдела и понятые - значит подозрение возникло. А экспертиза показала обратное. но что поделать - сложный случай. сразу и не разобрались :)
И вот еще, такое сообщение прошло на внутреннем форме одной компании:
"У нас в филиале в Нижнем Новгороде сегодня собака с милицией (С) забрала линуксовый сервер. С формулировкой - нет иконки "Мой компьютер", значить, не лицензионное. Вот так." :)