Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Разработка информационных систем Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Значение процесса проектирования информационных систем  [new]
Дмитрий Морочко
Member

Откуда:
Сообщений: 7
По многолетним наблюдениям организации проектирования программно-аппаратных систем в ИТ компаниях и крупных компаниях, организующих внутреннюю разработку, проектирование чаще рассматривается как часть процесса документирования систем. Часто используются развитые средства проектирования, тип Sparx Enterprise Architect (средство проектирования с использованием UML, BPMN и ряда неформальных нотаций), но в основном для «иллюстраций» проектной документации. Это, конечно, неплохо, но теряется главная идея систематического проектирования с использованием стандартных инструментов и нотаций – само проектирование систем – поддержка творческого процесса проектирования техническими средствами, коллективный творческий процесс.
К сожалению, в последнее время, многие разработчики программно-аппаратных систем, воспринимающие Agile методологию «буквально», стараются избегать процесс проектирования вообще, полагаясь на «быстрое» кодирование, демонстрацию системы овнеру и коррекцию требований к системе.
Проблема в том, что проектирование – объективный, неизбежный процесс при разработке программно-аппаратных систем. Разница в подходах:
• Системный подход, основанный на знаниях по разным аспектам проектирования. Моделирование является частью систематического подхода.
• Несистемный подход. Часто «в уме», в «разговорах», как правило не основывается на знаниях в областях проектирования. Очень нравиться «начинающим» программистам – они считают, что, научившись кодировать они уже достигли всего, никаких новых знаний и умений уже не надо (принцип, если я чего-то не знаю, то это не нужно и вредно).
По сути, проектирование систем, очень соответствует Agile концепции (если не относиться к некоторым методологиям «буквально»). Проектирование (может быть итеративным – «релизным») дает «быстрое» представление о будущей системе для различных групп заинтересованных лиц (заказчики, руководители проектов (спонсоры), аналитики, архитекторы, программисты, тестировщики, специалисты по внедрению, …). Обратная связь (корректирующая информация) приводит к уточнению модели системы, как следствие сокращение количества итераций по разработке (в частности программированию) системы. Учитывая, что проектирование системы – существенно более дешевый и быстрый процесс чем разработка (включая программирование), проектирование приводит к удешевлению и ускорению общего процесса разработки системы.
Много приходилось участвовать в проектировании систем с конца 1990х до настоящего времени. Сначала это был Oracle Designer 2000, потом Rational Rose (UML), средства проектирования IDEF, сейчас, в основном, Sparx Enterprise Architect (UML, BPMN, …). Проектирование включает много аспектов (соответственно роли проектировщиков), например:
• Бизнес анализ;
• Системный анализ;
• Архитектура;
• Дизайн программно-аппаратных компонентов;
• Сценарии тестирования.
Взаимосвязь моделей по всем аспектам проектирования является одной из основополагающих концепций наиболее распространенной методологии проектирования TOGAF (IBM, Oracle, Мин обороны США, NASA, …). В терминах TOGAF это понятие Enterprise Continuum.
Бизнес анализ включает описание бизнес-процессов, бизнес-объекты данных, роли участников бизнес-процессов, и.т.д.. Сценарии бизнес-процессов, взаимосвязи сценариев бизнес-процессов, трансформация бизнес-объектов (входящие, промежуточные, исходящие) в рамках сценариев бизнес-процессов, связь между ролями участников бизнес-процессов и бизнес-процессами – все это трудно представить без корректной бизнес-модели. Если для незначительной по размерам бизнес области обойтись мез модели можно (но трудно), то для средней и большой бизнес области это практически невозможно (хотя на практике встречал «гениальных» людей, перемножающих 7 значные числа «на лету»).
По результатам бизнес-анализа выявляются проблемы и потребности бизнеса, которые могут служить входной информацией для следующего этапа проектирования – системного анализа. Модели бизнес-анализа позволяют отслеживать связи между бизнес-проблемами (потребностями) и другими аспектами бизнес проектирования (бизнес-процессами, бизнес-объектами, ролями, …), не позволяя им «подвисать» (не понятно откуда и для чего).
Проектирование требований к системе (систематическое или «умозрительное» бессистемное) без этапа бизнес анализа возможно если бизнес область хорошо известна разработчику. В противном случае на этапе системного анализа возникают большие риски:
• Разработчики системы не охватывают существенных проблем и потребностей бизнеса;
• Разрабатываемая система не «укладывается» в текущую или изменяемую (планируемую) бизнес среду (бизнес-процессы, бизнес объекты, роли, …).
В процессе системного анализа необходимо контролировать взаимосвязь (термин «трассируемость») между требованиями к разрабатываемой системе, проблемами/потребностями и другими объектами бизнес-анализа (бизнес-процессы, бизнес объекты, роли, …). Без моделирования требований к системе и объектов бизнес анализа отследить «трассируемость» сложно (для небольших систем) или невозможно (для больших).
Требования к системе, формируемые на стадии системного анализа, кроме «трассируемости» на объекты бизнес анализа должны учитывать другие существенные аспекты:
• Полнота требований. Должно быть ясно, откуда и как система получает исходные данные, как обрабатывает, куда и как передает. Не должно быть «темных пятен».
• Непротиворечивость требований;
• Отсутствие дублирования требований (прямое и косвенное);
• Однозначность требований;
• «Трассируемость» требований разных типов, разных уровней иерархии (функциональные, нефункциональные, ограничения проектирования, требования к объектам данных, роли пользователей, …). Значению связи между функциональными и нефункциональными требованиями большое значение придается в сервисно-ориентированной ИТ методологии ITIL (международный стандарт), в частности аспект QoS (качество ИТ сервиса).
Без «понятного» моделирования требований обеспечить вышеуказанные аспекты системного анализа сложно или невозможно. Отсутствие моделирования приведет к высокому риску ошибок проектирования, как следствие большим издержкам на стадии разработки системы в виде переработок.
Далее процесс разработки архитектуры системы.
Для начала, необходимо контролировать «трассируемость» между объектами архитектуры (модули, компоненты (программные и аппаратные), алгоритмы, интерфейсы, фреймворки, …) и объектами системного анализа (требования (функциональные и нефункциональные), информационные сущности, роли, …). В противном случае система не решит поставленных задач (или решит «неудовлетворительно»). Опять-таки, без моделей отследить такую «трассируемость» сложно или невозможно.
Другие существенные аспекты архитектуры:
• Инфраструктура системы;
• Разбиение системы на компоненты.
Выбор программной (фреймворки) и аппаратной инфраструктуры системы «сильно» зависит от нефункциональных требований к системе и характера используемых компонент (программных и аппаратных). Необходимо внимательно контролировать эту зависимость.
Разбиение системы на компоненты (программные и аппаратные) имеет следующие аспекты:
• Максимизация повторного использования компонент существенно сокращает стоимость и срок разработки системы, повышает качество системы;
• Широкое использование стандартных («готовых») компонент;
• Горизонтальная и вертикальная компонентизация. При горизонтальной компонентизации, компоненты выполняют разные функции и мало взаимодействуют друг с другом. При вертикальной компонентизации, компоненты верхнего уровня используют компоненты более низких уровней (Типичный архитектурный шаблон – «архитектурные слои», например, слой пользовательского представления, бизнес логики, стандартных алгоритмов и общесистемных функций, внешних интерфейсов, данных, …).
Разбиение системы на компоненты, кроме возможности повторного использования компонент имеет другое, не менее важное значение – сокращение сложности, а следовательно стоимости и времени разработки системы, а также стоимости сопровождения и развития системы. Одна из наиболее распространенных моделей оценки сложности систем – COCOMO оценивает сложность системы, в частности, по количеству строк кода. Между сложностью (стоимость и время разработки) и количеством строк кода – степенная зависимость (количество строк в степени > 1).
Тенденция к компонентизации систем привело некоторое время назад к «модной» парадигме – микро-сервисная архитектура.
Спроектировать эффективную по структуре компонентную систему без использования моделей сложно (хотя есть и особо «гениальные» разработчики). Необходимо видеть эти компоненты, распределение функций между компонентами, связи компоненты, и.т.д.

О влиянии проектирования на стоимость, время разработки и качество программных систем, а также стоимость внедрения, сопровождения и развития систем можно обсуждать много. Не возражаю, что для небольших «коленочных» систем, мелких доработок, проектирование можно не проводить. Для средних и больших систем, «урезание» процесса проектирования, по многолетнему опыту во многих организациях, это путь к «провалу».
14 янв 20, 11:34    [22058627]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5066
Дмитрий Морочко
О влиянии проектирования на стоимость, время разработки и качество программных систем, а также стоимость внедрения, сопровождения и развития систем можно обсуждать много. Не возражаю, что для небольших «коленочных» систем, мелких доработок, проектирование можно не проводить. Для средних и больших систем, «урезание» процесса проектирования, по многолетнему опыту во многих организациях, это путь к «провалу».


Стоимость проектирования и стоимость прототипирования почти одинаковая.
Но прототип уже работает здесь и сейчас, а проектную документацию еще надо в код превратить.
Т.к. на данный момент в ИТ нет методик и стандартов 100% гарантирующих, что проект переведенный в код будет 100% удовлетворять требованиям заказчика, то зачем тратить деньги?
Когда можно выкатить MVP (прототип), а потом допиливать напильником.

Очень грубо говоря, agile это и есть проектирование. Только вместо красивых схем пишут код ;-)
14 янв 20, 12:08    [22058659]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
hVostt
Member

Откуда:
Сообщений: 16558
Дмитрий Морочко,

Чего вы там спроектировать хотите, если неизвестно, что будет завтра? Да и сегодня не всем понятно. Окромя великой идеи и набросков зачастую ничего нет :)
14 янв 20, 12:33    [22058694]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
hVostt
Member

Откуда:
Сообщений: 16558
mad_nazgul
Очень грубо говоря, agile это и есть проектирование. Только вместо красивых схем пишут код ;-)


Теоретически agile это движение к цели, к продукту через серию проверяемых маленьких инкрементов.

Можно потратить тысячи человеко-часов, нарисовать 100500 схем и пару томов ТЗ, а оно не только не взлетит, но и влетит в крупную копеечку.

Сообщение было отредактировано: 14 янв 20, 12:35
14 янв 20, 12:35    [22058696]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5066
hVostt
mad_nazgul
Очень грубо говоря, agile это и есть проектирование. Только вместо красивых схем пишут код ;-)


Теоретически agile это движение к цели, к продукту через серию проверяемых маленьких инкрементов.

Можно потратить тысячи человеко-часов, нарисовать 100500 схем и пару томов ТЗ, а оно не только не взлетит, но и влетит в крупную копеечку.


В любом случае, что через предварительное проектирование, что через мелкие итерации мы идем к цели.
Вопрос только в стоимости.

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

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

Вот когда стоимость машино-часа была очень дорогой. Тогда да. Разумнее было потратиться на "проектирование", а потом перевод в код.

Сейчас, когда в кармане мы носим вычислительные мощности, которые в прошлом веке даже и не снились, экономить машино-часы глупо.
А вот экономить человеко-часы разумно. :-)
14 янв 20, 13:08    [22058718]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
Zmeelov2
Member

Откуда:
Сообщений: 489
mad_nazgul
Практика показала, что дешевле сделать небольшой прототип, который потом можно "вырастить" до крупного приложения.
Практика показала, что плохо спроектированный небольшой прототип надо выкинуть и начать проект с самого начала. В то же время практика показала, что избыточно хорошо спроектированный прототип превращается в переусложненный нерасширяемый фреймворк, тормозящий разработку, который надо выкинуть и начать проект с самого начала. Так что проблема в поиске золотой середины.
14 янв 20, 13:53    [22058761]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
МодальноеОкно
Member

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


это нормально.

первый прототип всегда идет по сути в мусорное ведро. либо целиком сразу после показа и выслушивания заказчика с "я не это имел ввиду" или "по сути" в процессе рефакторинга и выстраивания архитектуры
14 янв 20, 14:02    [22058772]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
Zmeelov2
Member

Откуда:
Сообщений: 489
МодальноеОкно
это нормально.

первый прототип всегда идет по сути в мусорное ведро.
Мне больше интересно, как избежать эффекта второй системы. Он, оказывается, проявляется не только когда одна и та же команда делает вторую систему в жизни, но и в рамках одного проекта: прототип(макет) - "а теперь мы сделаем правильно"(вторая система). Как результат - переусложненная модель с возможностями расширения везде, где можно.
В разработке пришел к четырем постулатам:
0. Документация (постановка, правила обработки данных) ценнее кода. (Принцип правила первичны)
1. Делать надо только то, что нужно в данный момент. (Принцип минимальных усилий)
2. Любой блок надо делать максимально изолированным от остальных, предусматривать возможную замену. (Принцип черного ящика)
3. Расширение ведется в основном заменой блоков кода (Принцип расширения через замену)
14 янв 20, 14:38    [22058830]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2838
Zmeelov2
2. Любой блок надо делать максимально изолированным от остальных, предусматривать возможную замену. (Принцип черного ящика)
3. Расширение ведется в основном заменой блоков кода (Принцип расширения через замену)


в ООП для этого вводили концепцию SOLID
14 янв 20, 14:53    [22058858]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
Zmeelov2
Member

Откуда:
Сообщений: 489
МодальноеОкно
в ООП для этого вводили концепцию SOLID

Так отовсюду тянем ценностиКартинка с другого сайта.. И не ООП единым.
14 янв 20, 15:00    [22058872]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
hVostt
Member

Откуда:
Сообщений: 16558
МодальноеОкно
в ООП для этого вводили концепцию SOLID


в ООП? Картинка с другого сайта. Картинка с другого сайта. Картинка с другого сайта.

концепцию? Картинка с другого сайта. Картинка с другого сайта. Картинка с другого сайта.

Сообщение было отредактировано: 14 янв 20, 17:34
14 янв 20, 17:33    [22059068]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2838
hVostt
концепцию


сложное слово?
14 янв 20, 17:37    [22059072]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
hVostt
Member

Откуда:
Сообщений: 16558
Zmeelov2
0. Документация (постановка, правила обработки данных) ценнее кода. (Принцип правила первичны)


Если будет использовать именно так, как звучит -- don't work.
Если будет использоваться не так, как звучит -- тем более don't work.

Zmeelov2
1. Делать надо только то, что нужно в данный момент. (Принцип минимальных усилий)


Читай, либо из говна и палок на коленке, либо нужно потратить время на такое проектирование, чтобы потом не пришлось ничего переписывать, но при этом усилия должны быть минимальны. По сравнению с чем? Соберём колл, обсудим варианты?

Эхх.. не жизнь, а масленница.

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


Да ладно, не стесняйтесь, микросервисы only! Даётся ли это бесплатно?
Аххахах (слёзы), ну канешна парниш! Халява сыр!

Zmeelov2
3. Расширение ведется в основном заменой блоков кода (Принцип расширения через замену)


См. п.2, об одном и том же в профиль, в анфас, извините, сзади, много можно сказать. Но это сути не меняет.
14 янв 20, 17:39    [22059073]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
hVostt
Member

Откуда:
Сообщений: 16558
МодальноеОкно
hVostt
концепцию


сложное слово?


Знатные у вас выдумки и фантазии. Чего курите?
Или не курите, о SOLID в пол уха слышали? )))
14 янв 20, 17:40    [22059075]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5066
Zmeelov2
МодальноеОкно
это нормально.

первый прототип всегда идет по сути в мусорное ведро.
Мне больше интересно, как избежать эффекта второй системы. Он, оказывается, проявляется не только когда одна и та же команда делает вторую систему в жизни, но и в рамках одного проекта: прототип(макет) - "а теперь мы сделаем правильно"(вторая система). Как результат - переусложненная модель с возможностями расширения везде, где можно.
В разработке пришел к четырем постулатам:
0. Документация (постановка, правила обработки данных) ценнее кода. (Принцип правила первичны)
1. Делать надо только то, что нужно в данный момент. (Принцип минимальных усилий)
2. Любой блок надо делать максимально изолированным от остальных, предусматривать возможную замену. (Принцип черного ящика)
3. Расширение ведется в основном заменой блоков кода (Принцип расширения через замену)


Вся проблема в 1 пункте, т.к. обычно (на моей практике всегда) документация мало соответствует действительности.
Соответственно остальные пункты делают не то и не так.
Для этого как раз MVP нормальный подход.
Вместо того, чтобы делать бред, по документации мы делаем что-то что заказчик может потрогать и сказать свое "ФУ".
Далее идут уточнения. Хорошо если мы исходя из горячечного бреда заказчика сможем сразу боле-менее правильно сделать прототип.
Если нет, то прототип на свалку, благо на него потратили не более двух недель. Переписываем и идем дальше.

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

Если же менеджер/аналитик любит UML и показывает заказчику "веселые картинки", то 100% что будет все сделано не то и не так.

Главное получать как можно быстрее обратную связь от заказчика.

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

Так что, по моему опыту, если мне приносят кучу "веселых картинок" из UML, это значит, что ТЗ как минимум не полное, как максимум просто бред.
15 янв 20, 06:05    [22059382]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
Zmeelov2
Member

Откуда:
Сообщений: 489
mad_nazgul
Вся проблема в 1 пункте, т.к. обычно (на моей практике всегда) документация мало соответствует действительности.
Это действительно беда-беда. Кривое ТЗ, кривая схема БД, косое руководство пользователя. С другой стороны, правильное документирование (пусть мы даже исключим постановку задачи) проектных решений нетривиально и требует значительных ( по сравнению с собственно разработкой) ресурсов. Кроме того, есть недурственный риск забюрократизировать процедуру.
mad_nazgul
когда написали первую версию и показали клиенту, то оказалось, что БП описан не правильно и упущено куча моментов, которые для заказчика были само-собой разумеещимися, а аналитики просто про это не знали.
Вот-вот. Классическое кривое ТЗ.
mad_nazgul
Главное получать как можно быстрее обратную связь от заказчика.
Бесспорно. MVP это хорошая идея.
mad_nazgul
если мне приносят кучу "веселых картинок" из UML, это значит, что ТЗ как минимум не полное, как максимум просто бред.
А может, его просто нет
15 янв 20, 06:25    [22059384]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2838
hVostt
МодальноеОкно
пропущено...


сложное слово?


Знатные у вас выдумки и фантазии. Чего курите?
Или не курите, о SOLID в пол уха слышали? )))


вася, твое место в буфете
15 янв 20, 10:13    [22059469]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2838
hVostt
Если будет использовать именно так, как звучит -- don't work.
Если будет использоваться не так, как звучит -- тем более don't work.


Картинка с другого сайта.Картинка с другого сайта.Картинка с другого сайта.

вы кличко речи не пишите? очень похоже
15 янв 20, 10:15    [22059472]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2838
mad_nazgul
Был на одном проекте, где почти год потратили на аналитику и составление ТЗ.
А когда написали первую версию и показали клиенту, то оказалось, что БП описан не правильно и упущено куча моментов, которые для заказчика были само-собой разумеещимися, а аналитики просто про это не знали.
Хотя опыт у них был в проекте с той же предметной областью.
Но БП оказались довольно сильно отличающиеся в деталях.


по другому не бывает. особенно если аналитики деревянные по пояс - кроме правильного, без искажений, записывания ответа нужен еще правильный вопрос. а для правильных вопросов нужны мозги и опыт
15 янв 20, 10:18    [22059475]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
hVostt
Member

Откуда:
Сообщений: 16558
МодальноеОкно
вася, твое место в буфете


А, забыл, вы представитель местной быдлоты. Ясно.
15 янв 20, 11:14    [22059540]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
hVostt
Member

Откуда:
Сообщений: 16558
МодальноеОкно
Картинка с другого сайта.Картинка с другого сайта.Картинка с другого сайта.

вы кличко речи не пишите? очень похоже


От вас кроме соплежуйства и откровенного быдлячества, видимо ничего по сути не будет.
15 янв 20, 11:15    [22059541]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5066
Zmeelov2
mad_nazgul
Вся проблема в 1 пункте, т.к. обычно (на моей практике всегда) документация мало соответствует действительности.
Это действительно беда-беда. Кривое ТЗ, кривая схема БД, косое руководство пользователя. С другой стороны, правильное документирование (пусть мы даже исключим постановку задачи) проектных решений нетривиально и требует значительных ( по сравнению с собственно разработкой) ресурсов. Кроме того, есть недурственный риск забюрократизировать процедуру.


ТЗ как раз было не кривое. Оно просто описывало другое.
Повторю аналитики уже делали такой же проект с такой же предметной областью.
Просто оказалось, что заказчик очень своеобразно трактует стандарты.
Да и сами стандарты, скажем так имеют логические дыры.
Поэтому БП в прошлом проекте были не совсем такие как в новом.
А заказчик просто с умным видом читал гору литературы, которую нагенерили аналитики и подписывал.

"В общем все верно, в частностях все не верно" выяснилось только когда выкатили приложение на предпрод и реальные пользователи с ним стали работать.
15 янв 20, 14:03    [22059760]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5066
МодальноеОкно
по другому не бывает. особенно если аналитики деревянные по пояс - кроме правильного, без искажений, записывания ответа нужен еще правильный вопрос. а для правильных вопросов нужны мозги и опыт


Вопросы задавали правильные, но только потом, когда поняли что "Все врут".
А так до этого да большой проект, но подобный уже делали (масштабом поменьше).
Аналитики да молодые и возможно опыта не много (года три вроде)
15 янв 20, 14:11    [22059769]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
L_argo
Member

Откуда:
Сообщений: 1088
mad_nazgul
"В общем все верно, в частностях все не верно" выяснилось только когда выкатили приложение на предпрод и реальные пользователи с ним стали работать.
Вот это и главная ошибка. А не в каких-то там ТЗ недописанных или нет.
Заказчик должен увидеть куски прототипа как можно раньше.
Тогда будут наводящие вопросы и еще можно быстро и беспроблемно исправить.
И нестрашно, что многое там еще не дописано. Можно на словах добавить, что и где будет.
15 янв 20, 14:41    [22059814]     Ответить | Цитировать Сообщить модератору
 Re: Значение процесса проектирования информационных систем  [new]
ViPRos
Member

Откуда:
Сообщений: 9710
Если аналитик знает предметную область заказчика хуже чем сам заказчик, то нефиг браться за его задачи.
15 янв 20, 15:07    [22059841]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Разработка информационных систем Ответить