Posts filed under ‘Методы и технологии анализа’
ОЦЕНКА ЗАТРАТ И ТРУДОЕМКОСТИ РАЗРАБОТКИ ПО КАК СПОСОБ УЛУЧШЕНИЯ КАЧЕСТВА ТРЕБОВАНИЙ
Grigory Grin
Предлагаю вниманию читателей статью, написанную Григорием Грином для он-лайн журнала Requirements Engineering Magazine на английском языке и опубликованную 27 февраля 2019г
When the rubber hits the road – Improving requirements quality by effort estimates.
Мне показалось, что такой взгляд на оценку стоимости и затрат при разработке ИТ — проектов, в русскоязычных публикациях не встречается, и будет интересен нашим аналитикам и руководителям проектов. Перевод сделан мной и согласован с автором. Нэлли Грин
Введение
Существует ряд критериев качества требований. IREB Syllabus (1) группирует критерии по трем параметрам: содержание, документация и согласованность. Группа согласованность включает следующие три критерия:
- «согласованы»,
- «согласованы после изменений»,
- «разрешены конфликты».
Опыт автора показывает, что обычно невозможно получить надежное соглашение с заказчиком о наборе требований без сопутствующих оценок стоимости / трудоемкости реализации этих требований. Разумеется, такие оценки можно рассматривать отдельно от самих требований, как часть процесса коммерческих переговоров. Но влияние, которое оценки оказывают на требования и их описание, настолько значимо, что автор предпочитает рассматривать оценивание как неотъемлемую часть процесса разработки требований. С такой точки зрения «оценка» может рассматриваться как еще один критерий качества требований.
В представляемой статье рассматриваются взаимосвязи между требованиями и оценками затрат и трудоемкости.
Статья написана для варианта разработки ПО, при котором:
- разработка программного обеспечения контрактная, когда заказчик и подрядчик представляют собой две разных организации с их собственными целями и сложными отношениями между ними,
- контракт с фиксированной ценой fixed-price.
Автор имеет опыт работы по большей части на стороне подрядчика, поэтому статья может быть немного предвзятой.
Базовая концепция по оценке стоимости разработки ПО
Тем, кто только начинает работу по оценке программного обеспечения, можно порекомендовать отличную книгу по этому вопросу (2):
«Оценка программного обеспечения: демистификация черного искусства» от Стив Макконнелл, которая опубликована в 2006 году.
Ничто из этой классической работы не устарело в течение прошедшего более чем десятилетия. Это обязательное чтение для всех, занятых в отрасли разработки ПО.
Начнем с повторения некоторых основных концепций, представленных McConnell, а затем перейдем к другим темам, основанным на собственном опыте разработки автора статьи.
Сравнительно просто оценить параметры некоторых объективно существующих объектов. Например, высота дерева. Все становится сложнее при оценке чего-то в будущем, чего еще не существует. Для того же дерева — какова будет высота дерева через 5 лет? И еще более сложно, если оцениваемый показатель зависит от усилий, которые будут приложены в будущем.
В отношении разработки ПО обычно оцениваются общие затраты и/или трудозатраты, необходимые для реализации определенных требований или набора требований.
Здесь критически важно различать следующие понятия:
Estimate — Оценка — это прогноз, предположение или мнение. Например: мы можем быть готовы через 4-6 недель.
Target – Цель, которая может быть зафиксирована в плане или ином документе. Например: нам нужно представить релиз до начала сезона отпусков.
Commitment — Обязательство — это обещание (возможно, закрепленное договором). Например: релиз будет представлен к 1 ноября.
Рисунок 1 – и оценка и цель влияют на обязательство
Типичная проблема заключается в том, что, когда люди спрашивают вас об оценке, они на самом деле больше заинтересованы в получении от вас обязательства, вероятно, в соответствии с собственным планом.
Другим важным моментом в определении оценок является то, что они не простые числа, они являются распределениями вероятностей. Если вы скажете, высота дерева через 5 лет составит 4,52 м, вы на 100% уверены? 60% уверены? Какова вероятность того, что дерево вырастет до высоты между 4,5м и 4,6 м? Насколько она отлична от вероятности того, что дерево будет находиться между 4 и 5 м? Всегда гораздо полезнее указать диапазон и задать вероятность того, что целевой параметр находится в этом диапазоне. Например. Я на 90% уверен, что дерево будет между 4 и 5 м.
На приведенном ниже рисунке показано типичное распределение вероятности для оценок ПО. Для любого конкретного значения по оси X имеется соответствующая вероятность на оси Y. Существует естественный нижний предел оценки, ниже которого вероятность становится равной нулю. Но нет верхнего предела (работа может занять любое время, хотя вероятность роста трудоемкости с какого-то её значения уменьшается).
Рисунок 2 Оценка как распределение вероятностей. Рисунок из упоминавшейся книги McConnel-а (Рис.1-3)
Ещё один терминологический аспект, который важно отметить, это разница между (accuracy) правильностью, достоверностью оценок и их (precision) точностью.
Оценка, выраженная в виде интервала, является достоверной, если оценочный параметр действительно находится в указанном диапазоне (от 4 до 5 м в приведенном выше примере про дерево). Точность — это длина интервала (1 м в том же примере). Мы хотим, чтобы наши оценки были в первую очередь достоверными, и лишь потом – настолько точными, насколько это необходимо. Типичная проблема заключается в очень точной оценке, которая не является при этом достоверной. Проект займет 4-5 недель (для проекта, который займет 3 месяца).
Достоверность прогноза может быть оценена только ретроспективно, когда известна действительная величина прогнозируемой переменной. Точность может быть определена априорно.
В книге (2) подробно описываются и обсуждаются очень полезные методы оценки, которые выходят за рамки данной статьи.
Оценки и управление проектом
Для автора основным заявлением книги МакКоннела (2) стало следующее:
«Когда мы сделали оценку и, исходя из этой оценки, оформили обязательство о предоставлении функциональности и качества ПО к определенной дате, мы управляем проектом для выполнения этого обязательства, которое становится ограничением проекта».
Рассмотрим это утверждение более подробно.
У разработчика обычно запрашивают оценки затрат при согласовании нового проекта с клиентом, когда требования выявлены и задокументированы (это для разработчика вход), и в этот момент необходима оценка трудоемкости, чтобы можно было установить цену (выход).
Несмотря на то, что соотношение между ценой, предлагаемой клиенту и внутренней оценкой затрат, может быть различным, ясно, что между ними существует четкая зависимость.
После подписания контракта, когда проект начинается, принятое обязательство больше не может быть изменено (без существенных переговоров).
Рисунок 3 Процесс оценки до подписания контракта.
Предварительная оценка стоимости в интервале 200 -250 тыс. евро, первоначальное предложение заказчику 230 тыс. евро, после согласования контракта окончательно утвержденная цена – обязательство – 210 тыс. евро.
Для проектной команды цена из контракта теперь является обязательной и переставая быть выходом, становится частью входа.
Рисунок 4 Процесс после утверждения контракта – обязательство теперь часть входа, дополнительное требование для проектной команды.
Команда проекта должна вести проект таким образом, чтобы в результате работы над ним фактические затраты оставались ниже цены, закрепленной контрактом. Теперь уже речь идет не о корректности оценки, а о прибыльности (безубыточности) проекта.
Интересно, что другой входной параметр — требования, которые должны были быть зафиксированы в процессе согласования цены — теперь должны рассматриваться более гибко, поскольку конкретизация требований и выбор варианта дизайна окажут существенное влияние на фактические затраты и конечный финансовый результат.
Это может показаться очевидным, но многие недостаточно опытные команды автоматически приступят к выполнению обещанного объема работ как самой важной цели, и их собственные издержки могут оказаться при управлении проектом вне фокуса до тех пор, пока проект не превратится в убыточный.
Команда проекта может (и должна) выполнять переоценку предполагаемого объема работ и затрат и в начале проекта, и в дальнейшем — в ходе его продолжения. При этом, не достаточно лишь спрогнозировать, что проект с фиксированной ценой в 210тыс евро закончится с затратами в 300тыс евро. Необходимо своевременно обратить внимание на эту ситуацию, и принимать все необходимые контрмеры, чтобы вернуть проект в прибыльный форватер.
Можно, например :
• Целенаправленно выбирать способы решения с учетом минимизации трудоемкости разработки;
• Активно управлять ожиданиями клиентов;
• Мониторить взаимоотношения с клиентами с целью своевременного формулирования запросов на изменение требований (CR) и получения дополнительного финансирования в случае значительного увеличения трудоемкости проекта;
• В худшем случае, повторно согласовать цену контракта с клиентом.
В зависимости от ситуации на этапе заключения контракта продавцы могут выбрать цену, которая находится в разных областях на кривой вероятности оценки. Когда команда начинает проект, надо точно знать, где именно находится цена в этом распределении вероятностей. Если известно, что цена была установлена в нижней части расчетного диапазона, руководитель проекта будет вести себя совсем иначе (гораздо более агрессивно), чем если бы цена находилась в верхней части диапазона.
Представление оценки
До сих пор оценка рассматривалась так, как если бы это было единственное число (или более правильно – единственное распределение вероятности) для всего проекта. Даже если этот вариант важен как общий результат процесса оценки, полезнее представлять оценку в более сложном комплексном виде.
По опыту автора, оценку имеет смысл представлять как минимум, в виде таблицы с разбиением на функции проектируемой системы, где каждая строка в таблице представляет собой функцию (или под — функцию). Может быть один или два уровня разбиения (больше возможно, но нецелесообразно). В колонке комментариев можно зафиксировать допущения, сделанные при оценке и / или другую полезную информацию.
Неважно, какая именно используется структура разбиения на функции. Важно, чтобы это была структура, которая хорошо согласуется с другими частями проекта, (например, со Спецификацией требований) и помогает лучше понимать оценку.
Пример:
Рисунок 5 Таблица оценок с двухуровневым разбиением функций
Основой для оценки является документ, описывающий требования (например, SRS — Спецификация требований к программному обеспечению). Если он структурирован хорошо, разбивка для оценки может следовать структуре документа — его заголовкам, а возможно, даже и индивидуальным требованиям. Однако во многих случаях документ, описывающий требования, структурирован таким образом, что использовать его структуру для описания оценки затруднительно. В этом случае специалист, выполняющий оценку, будет создавать свой собственный функциональный разрез, который в большей степени основывается на будущем решении и строится вокруг объектов, присутствующих в решении, — его компонентах и функциях.
В случае, если система состоит из нескольких компонентов, причем одни и те же функции могут быть представлены в нескольких компонентах, компонентный разрез следует добавить в таблицу оценок, чтобы сделать её еще более понятной.
Это особенно важно в случае, если отдельные компоненты разрабатываются разными командами. Тогда такая разбивка оценки показывает предполагаемую нагрузку на команды.
Рисунок 6 Таблица оценок с разбиением на функции и компоненты
Такую матрицу оценок можно сохранять в электронной таблице, например, используя Microsoft Excel. Важно, чтобы эта электронная таблица оценок изменялась синхронно с соответствующими спецификациями требований – каждой версии спецификаций требований должна соответствовать таблица оценок, им должен быть присвоен один и тот же номер версии. Даже без сложного инструмента управления конфигурацией отдельная версия файла оценок может быть сохранена с суффиксом версии в его имени, например. «Project_Estimate_v2.0.xlsx». Различия между версиями можно указать просто путем окраски изменяющихся / добавленных / значений. Это позволяет всем заинтересованным сторонам видеть, как изменились оценки в связи с изменениями требований. Если необходимо, история версий может храниться в одном файле отдельными листами таблицы.
Первый вариант такой оценки должен быть разработан командой продаж во время подготовки контрактного предложения. Помимо собственно оценки затрат, он должен содержать расчеты, объясняющие, как предлагаемая цена получается из этих оценок. Это очень полезно для использования в будущем.
Другой вариант оценки должен быть подготовлен командой проекта после начала работы, и затем оценки следует периодически пересматривать. Отклонения от оценки команды продаж должны обсуждаться и согласовываться между командой проекта и командой продаж. Эти отклонения обычно вызваны разным пониманием командами объема работ и предлагаемого решения. Разбиение на функции в оценках команды продаж и проектной команды тоже могут быть разными, поскольку проектная команда использует при разработке оценок гораздо более подробную информацию о проекте.
Оценки в жизненном цикле управления требованиями
В последней части речь пойдет о сроках, когда процесс оценки должен быть запущен.
Автору часто приходилось видеть подход «водопада» в процессе обсуждения контракта:
• Мы начинаем с анализа. Мы говорим с клиентом, чтобы понять его потребности. Мы записываем все в длинный документ требований. Мы формулируем нефункциональные требования. Мы проводим несколько циклов обсуждений и согласований с клиентом. В конце концов мы получаем спецификацию требований в «согласованном» состоянии.
•Теперь мы оцениваем трудоемкость, основываясь на согласованных спецификациях.
• Дальше мы делаем коммерческое предложение с ценой, основанной на оценке трудоемкости и затрат.
• Наконец, мы надеемся получить подписанный контракт и не можем дождаться начала разработки.
Вместо этого мы часто удивляемся, когда клиент, впервые увидев цену, внезапно меняет свое мнение, исключает половину функций из объема работ, меняет требования, просит альтернативные решения и / или объяснения или, в худшем случае, просто отказывается от проекта или обращается к другому разработчику.
Это происходит, потому что для клиента польза (результат), которую он получит от нашего предлагаемого решения, очень сильно зависит от цены, которую он должен платить за это решение. Если цена слишком высока, начинается переосмысливание важности для клиента сформулированных требований. Это объясняет, почему во многих случаях клиент запрашивает цену (или хотя бы предварительную «оценку»), прежде чем исполнитель сможет провести разумный анализ.
Позиция автора состоит в том, что процесс формирования спецификации требований должен идти параллельно с процессом оценки, и что оценка (в форме электронной таблицы, описанной выше) является дополнительным представлением спецификации, а наличие «оценки» является важным критерием качества требований (для процесса «согласование требований»).
Вряд ли имеет смысл отправлять текст спецификации требований клиенту, если у него нет представления о цене. Конечно, многое зависит от конкретной ситуации. В любом случае рискованно вкладывать слишком много средств в документацию по требованиям, не предоставляя клиенту одновременно возможную цену будущего решения.
Это предполагает более итеративный подход к подготовке контракта, начиная с укрупненных первоначальной спецификации и проекта контракта, с постепенным уточнением того и другого с учетом результатов обсуждений и согласований с клиентом.
При этом, речь идет не только об отношениях с клиентом. Уже отмечалось, что коммерческий результат является одним из наиболее важных ограничений проекта. Следовательно, также ои во внутреннем документе спецификация (текст) и оценка затрат (таблица) проектируются параллельно. Спецификация не может считаться завершенной, если для нее нет оценок трудозатрат. Разработчики должны читать требования через призму оценки их трудозатрат, и они должны проектировать решения с учетом заранее заданных ограничений по трудоемкости.
Заключение
Оценки для реализации требований очень важны в процессе разработки программного обеспечения. Они оказывают влияние на разных этапах:
• На этапе согласования контракта оценка затрат является базой для цены.
• Во время процесса разработки ПО цена (оценка, ставшая обязательством) является одним из основных ограничений, влияющих на выбор вариантов дизайна и решения.
• Оценка трудоемкости и затрат является предметом регулярных обсуждений между техническими и коммерческими командами, что ведет к лучшему взаимопониманию между ними.
• Важно включать этап оценки уже в самом начале процесса разработки требований, чтобы избежать неприятных сюрпризов, когда уже много усилий было вложено в анализ.
Автор предлагает рассматривать оценки как неотъемлемую часть требований, как их дополнительный атрибут. При такой точке зрения «оценено» может рассматриваться как еще один критерий качества требований (в группе «согласование требований»).
Ссылки
(1) IREB CPRE Foundation Level Syllabus: https://www.ireb.org/en/downloads/tag:syllabi
(2) Steve McConnel, “Software Estimation: Demystifying the Black Art”, Microsoft Press, 2006.
Об истоках водопада -к вопросу о трансформации модели разработки ПО
Превратившаяся в большую индустрию и быстро развивающаяся отрасль разработки программного обеспечения на всем пути развития занимается, в том числе, и методологией разработки, и моделированием процессов.
Но мало кто из практикующих разработчиков интересуется истоками, динамикой развития, тем что, откуда и почему появилось.
Тем важнее, на мой взгляд, появившаяся сейчас возможность познакомиться с работами начального периода развития отрасли. Их не так и много было, и совсем мало стали доступны.
Этот пост – Анонс статьи «ГДЕ ИСТОКИ ВОДОПАДА? ЧИТАЕМ СТАТЬЮ «УПРАВЛЕНИЕ РАЗРАБОТКОЙ БОЛЬШИХ КОМПЬЮТЕРНЫХ СИСТЕМ».
Статья «УПРАВЛЕНИЕ РАЗРАБОТКОЙ БОЛЬШИХ КОМПЬЮТЕРНЫХ СИСТЕМ» была написана Уинстоном Ройсом (Winston Royce) в 1970 году, относительно недавно стала доступна в сети на английском языке, и активно обсуждается и критикуется. Полного перевода на русский обнаружено не было. Автор анонсируемой статьи – Григорий Грин – предлагает перевод статьи Ройса на русский язык и дает свои комментарии, исходя из более чем 25-летнего опыта работы в отрасли – и программистом, и бизнес-аналитиком.
Еще немного о BABOK® Guide v3 от вице-президента IIBA
«BABOK Guide v3 и будущее профессии бизнес-аналитика» –статья Kevin Brennan, CBAP, IIBA Executive Vice President and Chief Business Analyst
Статья была опубликована в мае до выхода текста релиза третьей версии и являлась введением и призывом к бизнес-аналитикам принять участие в обсуждении.
Краткое описание того, что в 3 версии новое, полностью соответствует последовавшему затем пресс-релизу, а вот вступление раскрывает перед специалистами в бизнес-анализе широкие перспективы.
12 мая будет опубликовано ревью Guide to the Business Analysis Body of Knowledge® (BABOK®Guide) version 3. Это результат в действительности глобальных усилий 70-ти волонтеров — писателей и сотен специалистов из более чем 20 стран и 15 отраслей, принявших участие в экспертизе и рецензировании.
Важнейшая вещь – это то, что наша работа еще не завершена. В течение 60 дней, начиная с 12 мая не только члены IIBA, но все бизнес-аналитики по всему миру имеют возможность принять участие в окончательной доводке документа, представить свои предложения, чтобы сделать BABOK ® Guide 3 еще лучше.
Мы гарантируем, что каждый, кто найдет время изучить новое руководство TheBABOK® Guide и пришлет свои предложения, будет услышан – каждый комментарий будет изучен.
BABOK® Guide v3 будет стандартом консенсуса нашего сообщества, совместно созданный стандарт профессии бизнес-анализа, и нам нужна ваша помощь, чтобы убедиться, в том, что новый документ правильно позиционирует наше сообщество относительно вызовов будущего.
Наша цель создания нового руководства BABOK® Guide v3 – отразить в документе наступившую важную веху в эволюции бизнес-анализа и установить новый стандарт деятельности путем расширения видения бизнес-анализа и позиционирования бизнес-аналитика в качестве ключевого фактора стратегических изменений в организации, который содействует инновациям, организационным изменениям и развитию стратегии сотрудничества.
Что мы уже знаем о BABOK® Guide Version 3?
О том, что IIBA (Международный институт бизнес-анализа) приступил к переработке BABOK® Guide (A Guide to the Business Analysis Body of Knowledge ) с целью подготовки версии 3, мы узнали еще в 2010 году.
В 2013 году было уже много публикаций и обсуждений концепций и предварительных материалов новой версии BABOK (правда преимущественно на английском языке).
И вот 12 мая 2014г IIBA предложила готовый вариант BABOK® Guide Version 3 для обсуждения специалистами, срок установлен до 11 июля.
business_concept c сайта И. Шамаева
Российские (и другие русскоязычные) аналитики – члены IIBA, да и просто те из заинтересованных специалистов, кто хорошо владеет английским языком, смогли за это время довольно хорошо познакомиться с новым руководством и его отличиями от действующей второй версии, но и для не владеющих языком есть материал, чтобы получить предварительное представление.
Летом 2013 года 2 наших специалиста: Александр Белин и Иван Шамаев сделали перевод статьи Rick Strempler «BABOK VERSION 3: WHAT BUSINESS ANALYSTS CAN EXPECT», опубликованной в мае 2013г.
Бизнес-анализ Сангвис ИТ Пеликан 3 волны ИТ в службе крови
Часть 3 Подсистема Доноры –Городской банк доноров и отведенных
В статьях тех 90-х годов я писала:
«..система «ПЕЛИКАН» представляет собой многоуровневую и многофункциональную систему, имеющую различные варианты настройки на объемные и структурные характеристики конкретного объекта службы крови.
В связи с тем, что в структуре предприятия “САНГВИС” одновременно работает 7 пунктов заготовки и переработки крови (Отделы Заготовки Крови — (ОЗК), преобразованные из отделов переливания крови, существовавших ранее в структуре лечебных учреждений), разработанная информационная технология была настроена на условия работы ОЗК (производственные площади, особенности технологии, интенсивность потока доноров, распределение функций в объединении, количество и квалификация сотрудников). В каждом из ОЗК … имеется своя локальная сеть. Система комплектуется из информационно- программных модулей так, что оказалась возможна ее реализация на 2-3 или даже одном (в зависимости от конкретных условий) компьютерах. При этом сохраняются все особенности и преимущества единой комплексной технологии обработки информации в каждом подразделении».
Это уже о всем комплексе информационных технологий. Если же пока говорить только о подсистеме «Доноры», то сейчас пора сказать о ее «размножении» (не хочу здесь употреблять термин «тиражирование» — пока) на другие отделы заготовки крови (после внедрения в главном корпусе – в ОЗК1). О том, что как только была налажена технология ведения картотек отвода от донорства (лиц и адресов неблагополучия), был приобретен персональный компьютер и налажен контроль по картотекам отводов на выездах, я уже упоминала.
Следующим шагом было постепенное внедрение во всех отделах заготовки крови контроля по картотекам отводов (то есть, как на выездах – на одном компьютере). (далее…)
Бизнес-анализ Сангвис ИТ Пеликан Бумажные картотеки
Часть 3 Подсистема Доноры — 4 Работаем без бумаг
«Довольно долго хранили под руками бумажные архивы, к которым обращались в случае необходимости, и еще очень долго (тогда так казалось) работали и с ИТ системой, и с бумажными картами. Но пришло время – и было снова принято организационное решение – Сангвис начал работать без бумажных карт».
Готовя этот пост, я бегло посмотрела, что сейчас пишут на эту тему, и поняла в очередной раз: как же мы были тогда смелы, и в тоже время наивны.
Наиболее активен в обсуждении этой темы в печати все тот же Б. Зингерман (он работает там же – в ГНЦ, и занимается примерно тем же. Но т.к. ГНЦ – это в первую очередь клиника, то его сфера – это не только служба крови, но автоматизация лечебного процесса. Последние годы его внимание в значительной степени сосредоточено на электронной истории болезни).
Так вот, в 2009г — в опубликованной cnews презентации – Зингерман говорит: «Ни один главный врач не готов отказаться от бумажной истории болезни (или ее части)».
AgileDays 2011
Самое время обобщить материалы по очередной конференции AgileDays.
Прошла 5-я профессиональная конференция AgileDays’11 4-5 марта в Москве.
Конференция проходила в три параллельных потока докладов разного уровня погружения в тему agile. Сессии конференции включали как доклады на общие темы, полезные для тех, кто пока только проникает в тему, так и детальный разбор реальных случаев применения от практиков индустрии. Программа конференции.
Все доклады прошли отбор Программного Комитета, который представлен экспертами индустрии: Сергей, Дмитриев, Асхат Уразбаев, Никита Филиппов, Сурен Самарчян, Евгений Кривошеев, Стас Фомин, Максим Гапонов.
Хэдлайнер конференции — Хенрик Книберг, Agile / Lean тренер компании Crisp в Стокгольме. (Он помогает компаниям добиваться успеха как в техническом направлении, так и с точки зрения человеческих взаимоотношений. За последние 15 лет Хенрик был техническим директором трех шведских IT-компаний и многим другим помог начать работу с использованием практик Agile и Lean. Он является автором книг «Scrum и XP: заметки с передовой» и «Kanban и Scrum: выжимаем максимум«. Обе они переведены на русский язык и пользуются большой популярностью в России. Хенрик является сертифицированным Scrum-тренером, а также членом совета директоров Agile Alliance и часто работает совместно с пионерами Scrum и Lean, такими как Мери Поппендик (Mary Poppendieck), Джефф Сазерленд (Jeff Sutherland), Девид Андерсон (David Anderson) и другими лидерами индустрии.
В рамках конференции прошел тренинг-сертификация «Scrum Master Certification», которую провел Хенрик Книберг.
Недавно опубликовано, что самыми лучшими докладами на #agiledays признаны доклады Тимофея Евграшина, Евгения Кривошеева, Романа Юферева.
WEB спонсором конференции в этом году выступила Компания CUSTIS.
Бизнес-анализ -Сангвис –АСУ Пеликан Структура Базы данных
Часть первая – наше техническое задание Продолжение
Итак, август 1989 года, условия начала нового проекта:
1. Новый для нас объект автоматизации, и работали мы как внешние разработчики
2. Полное отсутствие аналогов, публикаций, типовых решений – чего-бы то ни было, поэтому естественно, что это была заказная индивидуальная разработка
3. Полное отсутствие использования средств автоматизации на объекте и какого-либо опыта у пользователей
4. Обязательность использования стандартов во всех отраслях деятельности, где они существовали, и при создании информационных технологий, частности
5. Система должна была быть разработана для всей организации, а не для какого-то отдельного подразделения (со временем масштаб организации еще и вырос значительно).
6. Инициатором разработки АС являлось высшее руководство организации.
Бизнес-анализ -Сангвис –АСУ Пеликан Начало
Часть первая – наше техническое задание
Затеев свои мемуары, я уже писала о том как начиналось АСУ в Сангвисе. Даже достаточно подробно в заметке про 1990 год. Сейчас я немного повторюсь, но немного под другим углом зрения – уже с точки зрения особенностей самой разработки.
После первого знакомства с будущим Заказчиком (я предпочитаю говорить Пользователем), наша команда — воспитанники советской школы проектирования, объяснили ему, что начать надо с заключения договора на обследование и разработку Технического Задания.
В нашей команде никаких разночтений, разногласий не было, никому не пришло в голову предложить – «да зачем нам Техзадание, набацаем несколько АРМов, напрямую пообщавшись с пользователями».
Хочется мне с сегодняшних позиций понять – а почему мы были так в этом уверенны.
Отраслевые стандарты
(далее…)
AgileDays Екатеринбург 2010 завершилась
В Екатеринбурге 4 июня прошла первая в России региональная конференция по гибким технологиям — AgileDays Екатеринбург ‘2010.
Быть в курсе как работают разработчики — святая обязанность бизнес-аналитика.
Мастерская бизнес-анализа 