Впечатлен щедростью и заботой. Когда читаешь электронную книгу "Простая одержимость" и получаешь ее в бумажном варианте - это новогоднее чудо! А авто из "Назад в будущее" просто супер. Спасибо тебе, Дед Мороз из Волгограда!
Вы подняли несколько интересных вопросов, касающихся различия между заказчиком и пользователем, а также роли каждого из них в процессе приемки. Я согласен, что в идеале разработчик должен проводить тестирование и обеспечивать качество продукта перед передачей его заказчику. Однако, в некоторых случаях вовлечение пользователей может помочь выявить нюансы, которые не всегда заметны команде разработки. В разработке наукоемкого ПО это вполне общая практика.
Что касается смешивания понятий проекта и продукта, я понимаю вашу точку зрения. В статье я стремился показать, как различные подходы могут применяться в зависимости от контекста.
Вас устроит ответ, что курс «Управление проектами» (AFW, Германия), где выделяются этапы подготовка, структурирование, планирование, выполнение и завершение проекта? На схеме в целях упрощения в стадию инициирование включаю подготовка+структурирование+планирование.
Сформулирую вопрос по другому: если есть два массива — X, Y, то можно ли отдельно определить свою функцию f так, чтобы затем в коде писать Y = f(X) (без foreach c вызовом Y[i] = f(X[i]). Хочется максимально приблизиться к математической нотации.
А есть ли в D аналог rvalue-ссылок как в C++11? Актуально для случая, когда внутри map вызываются вложенные функции f(g(x)), а сам x имеет составной тип. Хотелось бы для g(x) не создавать временный объект.
Впечатлен щедростью и заботой. Когда читаешь электронную книгу "Простая одержимость" и получаешь ее в бумажном варианте - это новогоднее чудо! А авто из "Назад в будущее" просто супер. Спасибо тебе, Дед Мороз из Волгограда!
Вы подняли несколько интересных вопросов, касающихся различия между заказчиком и пользователем, а также роли каждого из них в процессе приемки. Я согласен, что в идеале разработчик должен проводить тестирование и обеспечивать качество продукта перед передачей его заказчику. Однако, в некоторых случаях вовлечение пользователей может помочь выявить нюансы, которые не всегда заметны команде разработки. В разработке наукоемкого ПО это вполне общая практика.
Что касается смешивания понятий проекта и продукта, я понимаю вашу точку зрения. В статье я стремился показать, как различные подходы могут применяться в зависимости от контекста.
Вас устроит ответ, что курс «Управление проектами» (AFW, Германия), где выделяются этапы подготовка, структурирование, планирование, выполнение и завершение проекта? На схеме в целях упрощения в стадию инициирование включаю подготовка+структурирование+планирование.
Также можно работать и с xls, а насчет xslx согласен, это работа с xml. Опять же все это упирается в давность написания кода
DPS здесь незаменим.