Програмные проекты
Управление требованиями к программному обеспечению
Rational DOORS
Только полноправные пользователи могут оставлять комментарии. TM Feed Хабрахабр Geektimes Тостер Мой круг Фрилансим. Хабрахабр Публикации Пользователи Хабы Компании Песочница. Добрый день, уважаемое хабросообщество! Я уже давно являюсь читателем этого замечательного ресурса и вот, наконец, решил попробовать и свои силы. Я заметил, что тема управления проектами на Хабре освещена довольно широко в соответствующем блоге, а вот об управлении требований ничего найди не удалось. Что ж, пришло время восполнить этот пробел! Введение В условиях современной экономики выигрывает тот, кто производит больше с меньшими затратами. Сокращение затрат возможно как с использованием более дешевого сырья и материалов, дешевой рабочей силы, оптимизации процессов, так и их автоматизации. Автоматизация не ведет к стопроцентному сокращению затрат, но позволяет обрабатывать большее количество информации с меньшими затратами. Основным инструментом автоматизации деятельности являются информационные системы. Информационная система — это совокупность информационного, математического, лингвистического, технического программного и другого обеспечения, а также персонала для оперативной подготовки информации для лиц, принимающих решения. КИС поставляются как в коробочном варианте, который предлагает стандартные решения для автоматизации задач, так и позволяют создать необходимый набор функций самостоятельно в режиме конструктора. Кроме того, многие разработчики корпоративных систем предлагают услуги по адаптации коробочных решений к нуждам конкретного предприятия — услуги кастомизации. Корпоративные системы являются продуктом интеллектуального труда, что позволяет им без больших материальных затрат легко тиражироваться и передаваться по каналам связи, в отличие от продуктов материального производства. Информационные продукты имеют гораздо большую возможность адаптации под нужные конкретного производства, в связи с чем встает задача получения исходной информации для разработки или адаптации информационной системы. Разработка большой и сложной системы не может быть завершена за один подход — итерацию. Это может быть связано как с большой сложностью самой системы, так и со сложностью ее адаптации. Тем не менее, возможно уменьшить объем работы для разработчиков за счет повторного использования кода из одного проекта в другом. Для того, чтобы выявить возможность повторного использования кода необходимо найти требования, которые данный код реализуют. Такие требования очень часто встречаются в продуктах, автоматизирующих одну и ту же предметную область на разных организациях, например, бухгалтерский учет или документооборот. Задача повторного использования требований является одной из задач решаемых управлением требований. Управление требованиями, выработка требований и определение требований — краеугольные камни успеха любого IT-проекта. В организациях, не располагающих достаточными возможностями бизнес-анализа, проекты в три раза чаще заканчиваются неудачей, чем успехом. Управление требованиями Перед тем, как управлять требованиями разберемся, что такое требование и что такое управление требованиями и зачем это нужно. Управление требованиями — процесс, включающий идентификацию, выявление, документацию, анализ, отслеживание, приоретизацию требований, достижение соглашений по требованиям и затем управление изменениями и уведомление заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего жизненного цикла продукта. Требование — это любое условие, которому должна соответствовать разрабатываемая система или программное средство. Требованием может быть возможность, которой система должна обладать и ограничение, которому система должна удовлетворять. В соответствии с Глоссарием терминов программной инженерии IEEE, являющимся общепринятым международным стандартным глоссарием, требование это: Условия или возможности, необходимые пользователю для решения проблем или достижения целей; Условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам; Документированное представление условий или возможностей для пунктов 1 и 2. Необходимо для приемки продукта или процесса потребителем или внутренним руководящим принципом обеспечения качества Так же глоссарий ITILv3 определяет такое понятие, как набор требований — документ, содержащий все требования к продукту, а также к новой или измененной ИТ-услуге. Требование должно обладать следующими характеристиками: Единичность — требование описывает одну и только одну вещь. Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует. Последовательность — требование не противоречит другим требованиям и полностью соответствует документации. Атомарность — требование нельзя разделить на более мелкие. Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано. Актуальность — требование не стало устаревшим с течением времени. Выполнимость — требование может быть реализовано в рамках проекта. Недвусмысленность — требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объекты и факты, а не субъективные мнения. Возможна одна и только одна его интерпретация. Определение не содержит нечетких фраз, использование отрицательных и составных утверждений запрещено. Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования. Проверяемость — реализованность требования может быть проверена. В соответствии с ITILv3 все требования в проекте можно разделить на следующие группы: Функциональные Functional — реализуют саму бизнес-функцию. Управленческие Manageability — требования к доступным и безопасным сервисам; относятся к размещению системы, администрированию и безопасности. Эргономические Usability — к удобству работы конечных пользователей. Архитектурные Architectural — требования к архитектуре системы. Взаимодействия Interface — к взаимосвязям между существующими приложениями и программным средствами и новым приложением. Сервисного уровня Service Level — описывают поведение сервиса, качество его выходных данных и другие качественные аспекты, измеряемые заказчиком. Распространенное программное обеспечение для управления требованиями В настоящее время широкое распространение получили такие системы управления требованиями как IBM Rational RequisitePro, Telelogic DOORS, Sybase PowerDesigner и Borland Caliber RM. Приведу краткие переводы основных функциональных возможностей приведенных систем, взятые с сайтов производителей. IBM Rational Requisite Pro Программное обеспечение Rational представляет лучшие практические методы определения требований и управления ими, которые обеспечивают экономию времени и средств, помогая в решении следующих задач: Сокращение объема доработок и ускорение выхода на рынок благодаря совместной работе с заинтересованными лицами. Повышение производительности труда за счет контроля над изменениями в требованиях и управлении ими. Минимизация расходов и рисков за счет оценки влияния происходящих изменений. Демонстрация соответствия требований благодаря полному отслеживанию требований. Rational RequisitePro помогает проектным группам управлять требованиями, создавать качественные сценарии использования, расширять возможности отслеживания, повышать эффективность совместной работы, уменьшать потребность в доработках и повышать качество. Снижает сложность благодаря подробным представлениям с возможностью трассировки, в которых показаны отношения между родительскими и дочерними элементами. Снижает связанные с проектом риски, показывая требования, которые могут быть затронуты изменениями требований более низкого или более высокого уровня. Обеспечивает совместную работу географически распределенных рабочих групп благодаря применению полнофункционального, масштабируемого Web-интерфейса и цепочек обсуждения. Обеспечивает сбор и анализ сведений о требованиях с возможностью точной настройки атрибутов и фильтрации. Повышает производительность труда, позволяя отслеживать изменения путем сравнения версий проекта с начальными характеристиками, описанными с помощью XML. Обеспечивает соответствие результатов проекта поставленным задачам и бизнес-целям благодаря интеграции со средствами IBM Rational для разработки и выпуска ПО. Первоначально DOORS разрабатывался только как средство управления требованиями в процессе разработки программного обеспечения. Однако идеи, заложенные в DOORS, оказались успешными и в настоящий момент система используется даже в кампаниях, которые не имеют отношения к разработке программного обеспечения, но вынуждены контролировать большой объем взаимосвязанной информации, например, при разработке инженерных систем. Из Telelogic DOORS можно получить следующую информацию: Статус выполнения работ по каждому требованию отдельно, а также по группе требований. Статус работы над всем проектом. Ответственное лицо для каждого требования или группы требований. Ресурсы, которые потребуются для реализации требования еще до его внедрения в проект. Связь между требованиями заказчика, пунктами технического задания, программами верификации, тестирования и задачами управления проектом. Класс, модель или чертеж, в котором конкретное требование реализовано. Borland Caliber RM Borland Caliber RM — это корпоративная система управления требованиями, которая облегчает совместную работу, что позволяет группам разработчикам подходить к вехам проекта вовремя и с запланированными затратами. Borland Caliber RM также помогает командам разработчиков удостовериться, что разрабатываемое приложение удовлетворяет пожеланиям конечных пользователей за счет непрерывного сбора пожеланий на всех этапах жизненного цикла от аналитиков, разработчиков, тестировщиков и других заинтересованных в проекте лиц. Borland Caliber RM обладает следующими функциональными возможностями: Централизованное хранилище требований для всех проектов, разрабатываемых IT-компанией. Адаптируемость — Caliber RM можно сконфигурировать для использования в любом проекте, что повышает эффективность процесса управления требованиями. Трассируемость требований — открытая архитектура Caliber RM позволяет связать требования с другими артефактами на всех стадиях жизненного цикла программного продукта. Поддержка большого числа клиентов — Caliber RM прекрасно интегрируется с такими системами разработки, как Microsoft Visual Studio, Eclipse на платформе Windows. Интеграция с другими продуктами Borland для поддержки полного жизненного цикла программного продукта. Другое ПО За кадром остались также достаточно известные системы управления требованиями, такие как: Sybase PowerDesigner OpenSource Requirements Management Tool RequirementsWin и другие Новый подход к управления требованиями Как можно понять из приведенного выше обзора программного обеспечения для управления требованиям все оно базируется на одном принципе — человек, а в данном случае, аналитик, вводит требование в систему, смотрит, нет ли такого требования в системе уже. Если требование в той или иной формулировке уже присутствует в системе, то заново его не заносит, а отмечает, как дублирующее. В связи с тем, что поиск схожих требований вручную является сложной и трудозатратной задачей, которая требует постоянного участия аналитика, то в процессе управления требованиями именно ее стоит автоматизировать в первую очередь. Чтобы реализовать возможность поиска и повторного использования требований необходима методика идентификации требований, представленных текстом на естественном языке. Тогда, представив требование не только как текст, но и совокупность некоторых концептов или лингвистических переменных станет возможным не только выполнять поиск сходных требований, но и использовать повторно созданные в процессе реализации требования артефакты. Под артефактами в данном случае не стоит понимать только исходный код, который реализует требование, но и жизненный цикл, которое оно прошло, то есть код не всегда можно использовать повторно из-за специфики задач, но можно получить консультацию у его разработчиков. При разработке нескольких продуктов для одной предметной области это становится актуальной задачей. Например, при адаптации системы электронного документооборота на нескольких предприятиях часто возникает ситуация, что на разных предприятиях разные документы проходят одни и те же маршруты в процессе жизненного цикла и функциональность, которая реализует эти маршрутры может быть использована повторно, пусть и без полного копирования. Предположим, что следующие требования описывают маршруты документов соответственно на предприятиях А и Б: Рассчитав расстояние Хэмминга между этими двумя требованиями мы получим единицу, так как они различны только в одной позиции и, следовательно, при реализации требования Б стоит обратить внимание на требование А и его реализацию. Естественно, решение о повторном использовании принимает уже разработчик или другое лицо, принимающее решение, но уже хорошо, когда есть варианты, где можно подсмотреть реализацию. Всем спасибо за внимание, жду комментариев. Алгоритмы 1,3k авторов , 2,3k публикаций. Математика авторов , 1,1k публикаций. Высокая производительность авторов , 1,2k публикаций. Python авторов , 1,8k публикаций. Разработка игр 1,2k авторов , 2,9k публикаций. Разработка под Android 1k авторов , 2,2k публикаций. C авторов , публикаций. Assembler авторов , публикаций. Программирование 2,9k авторов , 6,5k публикаций. Криптография авторов , публикаций. Добавить в закладки Александр Бармин darkneo карма. Сутки Неделя Месяц Уязвимость ВКонтакте: Мысль, которая выраженна в иллюстрации, в полной мере передает то, с чем обычно я сталкиваюсь по будням, только немного в другом сегменте! Нам такую картинку преподаватель по системотехнике рисовал ещё на первом курсе, до сих пор помню: За одну только эту иллюстрацию топик можно плюсовать! В процессе чтения, не уходило ощущение, что это текст из методического пособия или чей-то курсовой работы. Очень старался написать по-серьезному, поэтому и получилось формально. Для написания серьезных вещей академический слог не обязателен. Зачастую в проектах вообще сложно вытащить из заказчика требования как таковые. Буду рад если кто-нибудь поделится опытом именно получения требований, удовлетворяющим всем 10 пунктам. Зачем Вы все это написали? Позволю себе предположить — Вы хотели донести до читателей Хабра то, что знаете сами. Но, например, я, как человек, который сам является менеджером проектов, пролистнул это очень быстро — тонны слов и все неинтересно. Давайте на примерах — возьмите конкретный кейс, распишите для него эту теорию на практике. Если надо помочь — обращайтесь, помогу. Сделаем практическую конфетку из теоретической сухой статьи. Присоединюсь, тоже перелистнул очень быстро. Извините, порекомендую к чтению: Иллюстрация прям по этой книге. Правда, у одного знакомого CIO на стенке висел более пессимистичный вариант. Мне субъективно не понравилось освещение управлением требованиями с использованием тяжеловесных программных продуктов. Возьму на себя смелость заявить, что мало кто из хабросообщества сталкивается с очень крупными проектами, где стадия проектирования, формулирования требований, планирования несколько месяцев и использование таких систем управления требованиями оправданно. В реальности проекты меньше, сроки разработки меньше, на инструментарий не разоряются и один человек выполняет несколько обязанностей. Только по Rational был такой толстенный талмуд. Ни у кого нет времени все это осваивать, плюс не дадут, уволят раньше: Из-за этого от статьи ощущение оторванности от реальной практики. Это как после институтов приходят вчерашние студенты и начинают все делать по теории. Молодцы, что написали статью. Время — самый дорогой ресурс в разработке ПО, поэтому тратить его на излишнюю документацию расточительно. Описанное управление требованиями рассчитано на крупные проекты, которых на рынке не очень много. Для средних и мелких проектов, ИМХО, нужно не детально фиксировать требования, а быстро создавать прототип, получать feedback от пользователей и переходить к следующей итерации. Мышлению всегда проще работать, когда есть от чего оттолкнуться. А рассматривать сферического коня в вакууме — это, конечно, полезно для развития фантазии, но совершенно бесполезно для конкретных нужд разработки ПО. Нет, но фидбек можно использовать в процессе выявления требований. Вы имеете ввиду, что фидбек нужно анализировать и на основе имеющегося фидбека и своих соображений надо формулировать новые требования или корректировать старые? Эта иллюстрация — явная же компиляция из того классического варианта. Это может быть не верно если вы являетесь и заказчиком проекта и одновременно его разработчиком. По-моему это реклама ПО для управления требования к IT-проектам. Манера изложения напомнила институтские методички. Статья сухая, да и воды полно… А по делу — как раз недавно пытались с менеджером проекта поговорить — чтобы заказчик поточнее давал спецификации того, что он хочет. Ибо часто каждую нгеделю спецификации не только новые приходят, но и полностью противоречащие предыдущим. Правда я был на нескольких проектах — и такое, в большей или меньшей степени есть везде. В меньшей — если заказчик близок к основной тематике вашей компании или заказчик внутренний. Но, увы, мы работаем в аутсорсинге и такое случается крайне редко. Смиритесь или менйте работу. Это может происходить по разным причинам. И это учитывая что далеко не всякая организованная активность может называться проектом. ПОменялись фантазии — ок — строим новые. Есессно при условии что всякая работа требует денег и времени — если если нет — смените работу. Требования меняются — это не значит что кто-то идиот. Я бы даже сказал, что идиот тот кто не полагает что изменение требований — это нормально в некоторых проектах. У проектов где полностью пишутся требования свои болезни, в некоторых случях это большой риск того что пользоваться системой будет пользоваться невозможно ужасно неудобно. Да даже если и заказчик идиот — это не повод его бросать. Заказчик обычно не знает, чего он хочет. И тем более не знает, если это не разработка новой системы, а адаптация какой-либо системы под нужды заказчика. Заказчик в первую очередь заинтересован в том, чтобы его бизнес шел в гору, а не в том, чтобы у него была система. Если он не может сам адекватно объяснить, что от системы требуется, то задача аналитика как бизнес-консультанта ему навязать решение в конце-концов. Как раз для того, чтобы каждую неделю систему не переделывать и нужно управлять требованиями. ТЗ — тоже в определенной степени документ, регламентирующий требования. Согласитесь, когда оно жестко прописано разрабатывать гораздо легче. ТЗ как таковое тут не причём ТЗ вобще стало одним из buzzword в нашей отрасли. Юмор ситуации в том что, хотя это мало кто осознаёт, ТЗ ничего не гарантирует и ни от чего не защищает. Дело вот в чём. Есть заказчик, Есть Подрядчик. Заказчик их так или иначе оплачивает. И вот в какой-то момент — толи потому что по статистика все идиоты, толи потому что жизнь так устроена и обстоятелсьтва изменились, заказчик гововрит что ему нужно [не]совсем другое. Может похожее на ТЗ может не похожее. Но в любом случае — не то что нужно заказчику. Угрожать не оплатить этап работ? Требовать выплат неустоек предусмотренных догвоовром? Это опять — потеря времени, потеря денег, суды, а главное — если вам разработка для чегото была нужна — у вас её как небыло так и нет и в ближайшее время уже точно не появится. Перспективы подбного рода судебных разбирательств весьма туманны если честно. Дело в том что судья — он как бэ ничего в этом не понимает. И в своих суждениях он может опираться только на заключения экспертов. Каждая из сторон естесвенно представит своих экспертов. Мне кажется, что вам нужно определиться для какого типа людей вы пишите: И я думаю, что практический обзор одной системы имел бы большую ценность, чем поверхностный обзор функционала нескольких. Тогда зачем введено это условие? В этой ситуации — запрос уже не явлется требованием? Она помогает создавать иллюзию контроля и порядка. Это самое то место, где теория расходится с практикой. Согласен, и ITIL не идеален, но дает хорошую почву для начала работы и чем ближе ваши требования будут к описанным в стандарте, тем легче будет описанные там же методики использовать в реальных проектах. В общем смысле, по всем 10 пунктам можно вообще сказать одно — требование должно быть написано так, чтобы разработчик мог понять, что он должен разработать, а тестировщик протестировать. А главное — чтоб аналитик смог его потом найти, регистрируя новое требование про то же самое. Для меня было открытием, что требованиями вообще можно управлять отдельно. Иначе говоря, подсистема управления требованиями выделяется настолько явно, что автоматизируется как отдельный продукт. И здесь за глаза всем хватает Jira с кучей собственных модификаций, но суть та же. Требования оформляются тут ровно также, как задачи и баги, скажем. Этот набор, комплекс ПО, должен уже в целом управлять проектами, документооборотом и собственно организацией. Мне трудно поверить, что управление требованиями может быть единственным или хотя бы просто центральным звеном ПО организации. И вот как раз место такого продукта в общей системе управления было бы интересно увидеть. Впрочем, интерес достаточно отвлечённый. Я не думаю, что мне придётся когда-нибудь работать в организации достаточно монструозной, чтобы она нуждалась в таком комплексе ПО, где одними только требованиями управляет отдельный продукт. IBM предлагает линейку продуктов, которая замечательно интегрируется между собой. И да, мы ее используем — IBM ClearQuest для багов, IBM RequisitePro для требований и IBM Rational Rose для моделирования. Проекты, в которых это гораздо более управляемы чем те, в которых требования документируются просто в ворде и через него же согласовываются. Вопрос в том, каким инструментарием. Нам вот Jira хватает. Именно там идёт обсуждение, а в ворде. Текущая статическая версия подписывается сторонами, имхо вполне логично. Думаю, всё дело в размере проекта, количестве требований, их сложности, в количестве уровней вложенности и прочих зависимостей. В каких-то организациях без системы управления требованиями просто не обойтись, наверное. Но в подавляющем большинстве фирм внедрение такого комплекса ПО не оправдано. Так что для продвижения подобных решений надо бы ещё указывать, с какого именно момента внедрение этого ПО целесообразно. Баг-трекеры отчасти управление требованиями и реализуют… Как правило в степени, достаточной большинству. Интересный пост, только хочу внести коррективу. Во- первых для того что бы эффективно работали госты и стандарты требуется определенная зрелость бизнеса как у заказчика так и у интегратора, иначе простая трата времени и денег, со зрелостью у нас вообще проблемы. Ваша ситуация изображенная на картинка абсолютна типична на сегодняшний день. Решаться она должна комплексно, процесса управления требованиями недостаточно, Важно уметь применять лучшие практики различных стандартов ситуационно. Так же если вводится в проект понятие управление требованиями, необходимо одновременно вводить управление качеством продукта и управление конфигурациями, иначе требования сведут проект на НЕТ! Добавлю что большинство изменений требований на лету связаны с неопределенностями в проекте, которые необходимо устранять в самом начале. Неопределенные качественно цели 2. Заниженные бюджеты, вход в проект слоном 4. Борьба за статусность 6. Неадыкватное описание бизнеса 8. Так же повторюсь важна зрелость бизнеса как заказчика так и исполнителя. Среди всех стандартов и программ которые собраны у вас в кучу и непонятно каким образом корелируют друг с другом, вы забыли самое главное — то что для зрелых процессов ИТ рамочным является ИСО , уже манипулируя процессами внутри этого стандарта можно охватить все необходимые процессы для конкретного ИТ проекта. За список софта спасибо. В остальном статья тему сисек управления требованиями совсем никак, ни в малейшей степени не раскрывает. Основные грабли, из виденных мной, это: Если требования будут исполнены, а ожидания не удовлетворены, то обязательно настанет негативный результат проекта. Какие методики на этом поприще? Как только видит, сразу понимает, что хотел не этого. Система может быть построена почти всегда с точки зрения одного человека: Одновременно всем она оптимально отвечать не сможет чисса математически , максимум двоим-троим из десяти. Как выбрать ключевых и как заставить остальных подвинуться, не обижаясь? Иначе визы от остальных невозможно будет получить. Пункт 4 требует доказательств. Не верю, даже не смотря на упоминание математики. OLAP vs OLTP — для OLAP операторам нужна хорошая нормализация, для OLTP аналитикам нужна хорошая денормализация. Из OLTP быстро глубокого отчёта не построишь, с OLAP бизнес-процесс почти невозможен. В одной базе это не уместить. Первичное построение куба на данных OLTP долгий процесс, а кубы аналитику нужны постоянно разные. И такая система одновременно удовлетворит обе подгруппы пользователей. Все так и делают, где на OLAP-аналитиков начальство выделяет деньги. Где я не прав? Вы выходите за рамки обсуждения одной системы. Сам заказчик сразу два параллельных контракта делать вряд ли будет — риск учетверяется. Какие-то кубы стареют, какие-то заново проектировать. И опять это другой контракт — на оперирование OLAP. То есть вы уже согласны, что системы-подсистемы весьма разные, что пункт 4 о проекции справедлив, и дискутируем дальше? Контракт может быть всего один: Я по-прежнему считаю, что систему всегда можно сделать такой, чтоб она удовлетворяла требованиям всех групп её пользователей. В крайнем случае, за счёт включения в себя дополнительных подсистем. Ущемления отдельных групп пользователей могут быть лишь со стороны их начальства — заказчика системы, если это начальство будет не готово заплатить за те возможности системы, которые нужны только для этих групп. Реверс-инжиниринг делали, требования документировали? Давайте лучше, не переходя на обсуждение моего опыта, Вы продемонстрируете доказательство или хотя бы пример, подтверждающий это Ваше утверждение: OLAP vs OLTP, и это разные системы. И к тому же первая без второй не бывает. То, что OLAP зачастую делается и продаётся отдельно — не означает, что она не является подсистемой, ибо продаётся она всегда для интеграции в общую систему учёта. Игнорирование мнения по подсистеме от человека, не работающего с этой конкретной подсистемой — не является ущемлением его возможностей. Однако, если он дело говорит, а непосредственный пользователь упирается — это проблема непосредственного пользователя и его начальства. Но не заказываемой системы. Дык это живая практика, чего доказывать. Можно было бы и переписку по этому поводу приподнять, где-то на тех предприятиях она могла сохраниться. Но вам придётся поверить, что она была такая, эта переписка. Директору отчитываться акционерам, день не закрыт, финансист предварительные цифры дать не могёт, главбух ждёт когда аналитик докрутит перегруженную им базу, потому, что аналитик тоже даёт главу в отчёт директора. Кроме того главбух ждёт завершения своих транзакций — в банке сбой их системы. А вы рисуете какого-то сфероконического заказчика, который во всех головах имеет единое мнение и гладких контрагентов. Кто директору пообещал решение проблем, которые не могут быть решены — тот идиот или подлец. Сам директор видимо тоже не далёк от него… Ибо невозможно получить отчёт, завязанный на ресурсоёмкий анализ не до конца собранных ещё данных и на результаты не проведённых банком транзакций. И значит отчёт, если он таки нужен, должен быть независим ни от того, ни от другого. Например, опираться на результаты вчерашнего дня или прошлой недели. Или включать раздел с легко получаемой сводкой по незавершённым транзакциям и не проанализированной первичке. И акционеры вполне могут понять, если это представить в доступной форме, почему в отчёте нет той части, которую в принципе невозможно получить к заданному сроку. Вы зайдите к директору и попросите его убедить акционеров изменить формат отчётности. Тут, правда, встаёт вопрос бюджета, но если заказчик хочет удовлетворить все такие требования своих пользователей, то проблем быть не должно. Он просто скажет, что старший прав не особо вникая. И так по каждому вопросу. В результате получится система для директора, и не очень-то для оператора. Если директор идиот, а подрядчик бесхребетен — да, так и получается. Люди не идиоты, не льстите себе. Они некомпетентны в программировании и организации программистских проектов. Кроме того они заняты своими делами, чтобы дополнительно заниматься решением программистских проблем. И из этого этого вырастает пусть, возможно, не самый лучший вариант, но уже достаточно хороший и обоснованный. Человеческий фактор — это да… Книжки — про НЛП, может быть уместны окажутся?.. Дополнительные требования увеличивают ожидания. По букве контракта да и то если ТЗ однозначное , а по духу контракта удалить проблемы заказчика — нет. В лучшем случае будет плохая репутация. Нужно изначально не забывать одним из требований к системе указывать учитывать возможность развития и изменения требований, и исходя из этого сразу предусматривать достаточный уровень гибкости системы… Грамотный разработчик это знает, как минимум из негативного опыта, как максимум — из книжек и подобных бесед. Тут, правда, придётся подумать над условием выхода из цикла, и как заказчика с этим смирить… И действительно проще бывает обмануть, пообщещать золотые горы в первой же итерации — но на такой хитрый подход обычно накладывают ограничения субъективная совесть и объективные перспективы судебного разбирательства и выплаты неустойки… И приходится стараться быть реалистом и добиваться от заказчика того же. С другой стороны если исполнитель не знает куда заведёт проект, он просто прекращает им управлять. А что касается бесконтрольности — так на каждой итерации вполне реально оговаривать и бюджет, и сроки, и всю остальную конкретику. И пытаться контролировать их. Другое дело, что НИОКР планировать по строкам и бюджету всегда сложно…. Это пошаговые контракты одного проекта включающего несколько систем-подсистем. Вы пытаетесь разрезать систему по контрактам не на подсистемы уже, а на шаги квартальные шаги. В свою очередь этот метод тоже неплох, но срок и бюджет проекта в целом становится по определению неисчислимым. Тут свои грабли — раздражения коллектива заказчика от стресса длительного реверс-инжиниринга, необходимости задерживаться после работы для ведения и тестирования параллельной системы. В конце концов middle management саботирует работу напрочь. В общем, аффтар скрылся, предпочитая на вопросы не отвечать. Это очень и очень спорный вопрос. Можно доказывать вплоть до обратного. В современной экономике IT-компании переходят от понятий продукта к понятию сервиса, который не размывает грань между разработкой и поддержкой. Цены на рынке более-менее устоявшиеся. Причем, основные затраты уходят отнюдь не на разработку, а на т. Скажу курьезную фразу, но для такого вида бизнеса сервис делать качественные и законченные продукты невыгодно. Вы поставляете решение, и заинтересованы в постоянном спросе на него а не разовом заказе! А для этого Вы должны поставлять всегда наполовину сделанное решение. Огромные обороты при плачевном качестве продуктов, разрабатываемом на аутсорсинге в Индии. Оборот, получаемый от продаж не идет ни в какое сравнение с затратами на разработку. Активно пытается пропехнуть свои Rational, крича о том, что все работают неэффективно. Но если вы пропагандируете что-то свыше трёх названных схем, то я бы с вами не работал — не хочется сидеть на игле халтуры. Продуктами Rational пользоваться невозможно. Когда то казалось что это был cutting edge, однако похоже что IBM Rational просрали таки все полимеры. Для любого бизнеса делать качественные и законченные долгоживущие продукты не выгодно — рынок насытится и очередные экземпляры продавать будет некому. Продукт должен быть либо одноразовым типа пирожка , либо сподвигающим к совершенствованию, ремонту или замене. У вас случайно нет цифр доходов Toyota от продаж и сервиса? Я слышал краем уха, что объём сервиса настолько низок, что его выгодно сворачивать — надёжность продукции достаточно высока. Но Toyota не намерена снижать качество. Ну, возможно их маркетологи просчитали, что побуждений к замене на новые модели машин у их клиентов достаточные, чтоб можно было не огорчать их качеством, а привлекать…. В математике и логике достаточно одного контрпримера , чтобы опрокинуть заявление. Ну просто таки ОБЯЗАНЫ!!! Но даже так статья весьма хороша. Ибо обосновать обязательность ЛЮБОГО эргономического требования — совершенно нереально. По-моему, они бывают даже на законодательном уровне прописаны, то есть их обязательность априори известна. Так кто-нибудь какую то систему из перечисленных в статье использует? Или не из перечисленных. Указанные системы вроде достаточно старые, сейчас популярна идея реализовывать тоже самое на основе issue tracker-а как плюс — не надо заниматься интеграцией 2-х систем. Но есть особенность — иерархия требований может быть достаточно глубокой, так что полезно иметь в трекере возможность создавать иерархии задач большой глубины вложенности. Как можно понять из приведенного выше обзора программного обеспечения для управления требованиям все оно базируется на одном принципе — человек, а в данном случае, аналитик, вводит требование в систему, смотрит, нет ли такого требования в системе уже. На днях вышла книжка по разработке и управлению требованиями на базе Cradle. Альфа-версия доступна бесплатно, включает учебный проект, выполненный по книжке. Посмотреть содержание и скачать можно отсюда saturs. Метки лучше разделять запятой. Сейчас Вчера Неделя Уязвимость ВКонтакте: Три дня как все кассы в стране должны стать онлайн на самом деле нет 43k Интересные публикации Хабрахабр Geektimes. Секрет дешёвых светодиодных ламп GT. Быстрое удаление пробелов из строк на процессорах ARM. Первый в мире мобильный телефон без аккумуляторов работает по образцу советского шпионского жучка х годов GT. Tesla построит в Южной Австралии крупнейшую в мире аккумуляторную систему всего за дней GT. Дайджест интересных материалов для мобильного разработчика 03 июля — 09 июля. Настройка BGP Looking glass на базе OpenBSD 6. Алгоритм поиска наилучшего маршрута в linux. Разделы Публикации Хабы Компании Пользователи Песочница. Информация О сайте Правила Помощь Соглашение Конфиденциальность. Услуги Реклама Тарифы Контент Семинары.
Где геоданные на айфоне
Выполнить исполнительные схемы
Гора пидан приморский край на карте
Инн физического лица по паспортным данным
Все впереди стихи
Право и мораль скачать