powered by simpleCommunicator - 2.0.28     © 2024 Programmizd 02
Map
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Перспективы развития не простой системы
25 сообщений из 66, страница 2 из 3
Перспективы развития не простой системы
    #40130712
Никанор Кузьмич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вообще говоря, то, что обсуждается в топике, называется "технический долг". Что это такое, откуда берется, и почему это плохо, описано уже миллион раз, и прекрасно гуглится. Достаточно скинуть начальству ссылку на Википедию и/или выдачу гугла, а дальше оно пусть подумает денек-другой над полученной информацией. Что оно в итоге надумает - то и будет пределом его управленческих компетенций в данной ситуации.
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130723
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вообще говоря, то, что обсуждается в топике, называется "технический долг"..+1
И еще "фактор кирпича"
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130725
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Никанор Кузьмич
Вообще говоря, то, что обсуждается в топике, называется "технический долг". Что это такое, откуда берется, и почему это плохо, описано уже миллион раз, и прекрасно гуглится. Достаточно скинуть начальству ссылку на Википедию и/или выдачу гугла, а дальше оно пусть подумает денек-другой над полученной информацией. Что оно в итоге надумает - то и будет пределом его управленческих компетенций в данной ситуации.

Кстати, да.
Это именно технический долг.
И пытаться начальству сразу описывать детали - не лучшая идея.
Надо дать ссылку на определение, что такое технический долг, и сказать, что сейчас это стало большой проблемой. Если начальство захочет деталей - тогда рассказать.
Но более вероятно, что они не смогут / не захотят понять, о чем вообще идет речь.
Тогда - искать другую работу.
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130740
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Никанор Кузьмич
...
booby
давай-ка вот что, если не на карантине, сходи-ка в ближайший алкомаркет, да возьми себе бутылочку коньячка поприличней, исходя из личных предпочтений и пристрастий.
Во, отличный совет! Зачем нужно это ИТ, становись лучше алкоголиком...

Ага, наверно совет ознакомить руководство с концепцией технического долга куда как практичнее.

Если они на самом деле поймут, что это такое, и разумные люди, то первое, что сделают, это вообще прикроют лавочку с внутренней разработкой.

В данном случае, человек в растерянности сразу по нескольким основаниям, не все из которых вообще лечатся, хоть чем нибудь.
Прежде чем куда-то идти, хорошо бы бросить воевать с самим собой внутри себя.
Отчего бы так не попробовать с собой если не подружиться, то хотя бы поговорить, это может помочь увидеть ему ситуацию в каких-то новых цветах.
Или разложить ее для себя предварительно на лично важные и не очень обстоятельства.
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130751
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
booby
Никанор Кузьмич
...
пропущено...
Во, отличный совет! Зачем нужно это ИТ, становись лучше алкоголиком...

Ага, наверно совет ознакомить руководство с концепцией технического долга куда как практичнее.

Если они на самом деле поймут, что это такое, и разумные люди, то первое, что сделают, это вообще прикроют лавочку с внутренней разработкой.

Своя разработка иногда является более правильным выбором, чем заказная разработка или покупка коробочного решения.
Хотя бы по той причине, что технический долг при использовании коробочного решения тоже возникает и может быть еще более болезненным.
Например - внедрили люди 1С УПП...

Я бы так сказал - любая фирма, использующая ИТ решения (то есть - все))) должна научиться управлять техническим долгом.
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130786
RIO08
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Никанор Кузьмич
Вообще говоря, то, что обсуждается в топике, называется "технический долг".

Вообще то нет. Если вы читали внимательно, то "«Приблуда» соответствует процессам компании и полностью её устраивает".
Да есть костыли, но и это не критично, собственно при переработке всё будет исправлено и проблемой опять же не является.

Сложность получившейся "приблуды" запредельная, а начальство уверено, что всё просто. Причём сложность обусловлена, бизнесом, который крайне не стандартен + излишней автоматизацией и разработкой "со слов".

Пример (буквально сегодня всплыл вопрос, на тему что это такое): Надо нам иметь специализированную базу данных по специфичной теме. Были загружены данные из четырёх источников информации и объединены в одно целое. Время выполнения этой работы 2 месяца одним человеком. Эту же работу (очень очень похожую) в другой организации делали 3 человек и 3 месяца, причём очевидные косяки исправлены не были, зато делали по ТЗ (которое тоже какое то время писалось).
Запрос на исправление косяков прилагаю:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
WITH 
A
     AS (SELECT *, 
                DENSE_RANK() OVER(ORDER BY AA.x000x, AA.DMT, AA.KRT, AA.STRT) AS dr, 
                ROW_NUMBER() OVER(PARTITION BY AA.x000x, AA.DMT, AA.KRT, AA.STRT ORDER BY AA.rrrrr) AS rn
           FROM dbo.xxxxxxx_Bez_Dubley6 AS AA),
B
     AS (SELECT *, 
                DENSE_RANK() OVER(ORDER BY  BB.x000x, BB.DOM, BB.Kor, BB.[Str] ) AS dr, 
                ROW_NUMBER() OVER(PARTITION BY  BB.x000x, BB.DOM, BB.Kor, BB.[Str]  ORDER BY BB.[Sys]) AS rn
           FROM  dbo.yyyyy_x000x_XX AS BB)

INSERT INTO US_ZaprX 

     SELECT a.rrrrr, 

            b.[Sys], 
			a.rn,
			a.dr,
			b.rn as rnS,
			b.dr as drS
       FROM a
            OUTER APPLY
     (
         SELECT TOP 1 *
           FROM b
          WHERE A.x000x = B.x000x AND A.DMT = B.DOM AND A.KRT = B.Kor AND A.STRT = B.[Str]
                AND b.dr = a.dr
                AND b.rn >= a.rn
     ) AS b
      WHERE b.rn IS NOT NULL; 


Документации по работе нет никакой, делалась со слов...
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130788
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov
...
Я бы так сказал - любая фирма, использующая ИТ решения (то есть - все))) должна научиться управлять техническим долгом.

Оно, так вообще, умн о , конечно.

Но вот в конкретном случае, с чего должен свою рассказку человек начать:
с того, что "бизнес" ставит плохо формализованные задачи в стиле "сделай как вон там" и не раскрывает внутренние причины и связи предметной области, но давит сроками.
Или вовсе с другого, например с того, образование мое недостаточно, а еще я не согласен с местной "архитектурой".

И что немедленно изменится после похода - внезапно проявится отсутствующий в коде комментарий, тесты начнутся писаться сами собой, сложатся стопками тома ненаписанных ТЗ, а местный заказчик внезапно начнет растолковывать детали бизнес-процессов?

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

Содержательно, заявить тему и употребить слова про технический долг, вместо водки, значит только одно:
дело это важное, и начинать надо, уважаемый начальник, с добавления в него денег .
Оно же не сранью какой управление, а целым техническим долгом. А это - дорогое удовольствие .
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130794
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кароч, ТС, готовь три конверта...
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130802
Никанор Кузьмич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
booby
Если они на самом деле поймут, что это такое, и разумные люди, то первое, что сделают, это вообще прикроют лавочку с внутренней разработкой.
Ну да, и что? Для начальства это не самый плохой выход. Если повезет, они поймут, что это
s_ustinov
Некоторым организациям иногда везет, и они получают довольно хорошее решение за копейки.
- про них, и скажут студенту спасибо за то, что тот целых три года помогал экономить прорву денег.
booby
Прежде чем куда-то идти, хорошо бы бросить воевать с самим собой внутри себя.
С этим согласен на все сто.

RIO08
Никанор Кузьмич
Вообще говоря, то, что обсуждается в топике, называется "технический долг".
Вообще то нет.
Вообще-то да.
Если даже вы не понимаете, что такое технический долг, то шанс объяснить это вашему начальству становится нулевым.
Запасаемся попкорном, садимся поудобнее, шоу начинается.

И кстати, вы так и не ответили на главный вопрос: вы для себя-то чего хотите?
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130814
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RIO08
Никанор Кузьмич
Вообще говоря, то, что обсуждается в топике, называется "технический долг".


Да есть костыли , но и это не критично, собственно при переработке всё будет исправлено и проблемой опять же не является.


Это и есть - технический долг.

wikipediaТехнический долг (также известный как долг кодинга) — это метафора программной инженерии, обозначающая накопленные в программном коде или архитектуре проблемы, связанные с пренебрежением к качеству при разработке программного обеспечения и вызывающие дополнительные затраты труда в будущем. Технический долг обычно незаметен для конечных пользователей продукта, а связан с недостатками в сопровождаемости, тестируемости, понятности, модифицируемости, переносимости . По аналогии с финансовым долгом, технический долг может обрастать «процентами» — усложнением (или даже невозможностью) продолжения разработки, дополнительным временем, которое разработчики потратят на изменение программного продукта, исправление ошибок, сопровождение и т. п. Хотя увеличение технического долга как правило негативно влияет на будущее проекта, оно может быть и сознательным, компромиссным решением, продиктованным сложившимися обстоятельствами.
https://ru.wikipedia.org/wiki/Технический_долг
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130815
RIO08
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Никанор Кузьмич
Вообще-то да.
Если даже вы не понимаете, что такое технический долг, то шанс объяснить это вашему начальству становится нулевым.
Запасаемся попкорном, садимся поудобнее, шоу начинается.

И кстати, вы так и не ответили на главный вопрос: вы для себя-то чего хотите?

Вообще то нет! Или любую (подчеркнуто), проблему с используемым ПО можно объявить "техническим долгом". Очень легко повесить на проблемы ярлык, вроде данного, особенно с учётом несколько неопределенной формулировки понятия.
Я приведу дурной, но конкретный пример: Контора использовала MS Access (давно это было), пришёл "специалист" и объявил, что это не правильная и устарелая система, не имеющая документации нужного качества и нужно переходить на точку нет. Дело было в 2002 году... Любое используемое ПО накапливает проблемы, меняется бизнес, меняются идеологии программирования. Вон вчера смотрел на систему для биллинга, сделанную на чистом СИ, так там "ручками" правят даты с 1970 года... Почему они не купят, что нить посовременней?

Чего хочу... Поразмышлять над темой, может я не вижу каких то возможностей. Не люблю иметь только 2 варианта, это неправильно.
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130816
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
booby

Содержательно, заявить тему и употребить слова про технический долг, вместо водки, значит только одно:
дело это важное, и начинать надо, уважаемый начальник, с добавления в него денег .
Оно же не сранью какой управление, а целым техническим долгом. А это - дорогое удовольствие .

Правильно!
Речь должна идти про деньги!
Например, "студенту" надо увеличить зарплату раза в 4 + улучшить условия труда (отдельный кабинет с диваном и длинноногой секретаршей))). В таком случае стимулов прям щас валить у него поубавится.
Второе - надо нанять людей, которые помогут разработать правильную архитектуру и наладить процессы - ту же документацию писать.
И где то через пол года - год будет уже довольно приличная система, которую можно поддерживать и развивать даже в случае, если студент уйдет (снижаем фактор автобуса / кирпича).
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130819
RIO08
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov


Это и есть - технический долг.

Я читал. Вы когда нить работали с SAP R3?
Меня как то убеждали, что у этой штуки, технического долга нет...
(Собственно 1С, Аксапта, Навижн и иже с ними... )
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130821
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Никанор Кузьмич
s_ustinov
Некоторым организациям иногда везет, и они получают довольно хорошее решение за копейки.
- про них, и скажут студенту спасибо за то, что тот целых три года помогал экономить прорву денег.


Конкретно в моей истории для меня это тоже было выгодно - набрался практического опыта.

Правда, начальство потом слегка расстроилось, что я не планирую и дальше работать за тарелку супа. И мой намек, что они УЖЕ сохранили кучу денег как то им не очень понравился. Может, они действительно верили, что это всё стоит копейки?
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130824
RIO08
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov
Например, "студенту" надо увеличить зарплату раза в 4 + улучшить условия труда (отдельный кабинет с диваном и длинноногой секретаршей))). В таком случае стимулов прям щас валить у него поубавится.
Второе - надо нанять людей, которые помогут разработать правильную архитектуру и наладить процессы - ту же документацию писать.
И где то через пол года - год будет уже довольно приличная система, которую можно поддерживать и развивать даже в случае, если студент уйдет (снижаем фактор автобуса / кирпича).
Первое ДАААААААА!!!!
Второе ХЗ... Точнее второе будет намного дороже (более трудоёмко, более сложно, етс (более дорого вестимо)) первого... Просто поищите грамотного архитектора (не того который будет говорить, что он грамотный) за разумные деньги...
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130825
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RIO08

Я читал. Вы когда нить работали с SAP R3?
Меня как то убеждали, что у этой штуки, технического долга нет...
(Собственно 1С, Аксапта, Навижн и иже с ними... )

Работать, к счастью - нет.
А вот смотреть внутренности - приходилось... После этого очень-очень радовался, что не надо с ЭТИМ работать.

А то, что уверяли про отсутствие долга...
Например, на заборах много чего написано. А за забором - дрова.
У всех этих систем есть технический долг.
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130831
Никанор Кузьмич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RIO08
Никанор Кузьмич
Вообще-то да.
Если даже вы не понимаете, что такое технический долг, то шанс объяснить это вашему начальству становится нулевым.
Запасаемся попкорном, садимся поудобнее, шоу начинается.

И кстати, вы так и не ответили на главный вопрос: вы для себя-то чего хотите?

Вообще то нет! Или любую (подчеркнуто), проблему с используемым ПО можно объявить "техническим долгом".
Объявить - да, можно любую. Точно так же можно, придя в зоопарк, на клетке со львом написать "кролик". Вопрос о том, перестанет ли после этого лев есть мясо и перейдет на морковку, оставлю вам в качестве домашнего задания.
Да, в википедии написано немного размыто. Я потому и говорил - почитать, что проедлагает гугл по этому вопросу, а не только википедия. Технический долг - это работа, которую делать нужно, но разработчик не делает в течение некоторого времени, а откладывает на потом - то есть берет в долг у себя из будущего, фактически. Это может быть документирование, написание тестов, рефакторинг и т. п.
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130836
RIO08
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinov
У всех этих систем есть технический долг.
У всех сложных систем есть технический долг.
Примеров тьма, куда не копни, но стоит ли считать это проблемой мешающей использованию этих систем?
Я вот буквально недавно, поработал с Revit. Стоит немерено, декларируется как само совершенство... ПО написано в конце 90х, дорабатывалось дятлами, не могущими понять что делали предыдущие разработчики и ничего, работает.

Я 3 раза сталкивался со "студентами", первый раз ниасилил, требовалось переделать в многопользовательский режим некую прогу, второй и третий удачно перевел и запустил, причём второй "студент" взял меня потом на работу, правда когда ему дали отдельный кабинет с секретаршей он перестал заниматься программированием, к моему громаднейшему сожалению...
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130837
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RIO08
s_ustinov
У всех этих систем есть технический долг.
У всех сложных систем есть технический долг.
Примеров тьма, куда не копни, но стоит ли считать это проблемой мешающей использованию этих систем?
Я вот буквально недавно, поработал с Revit. Стоит немерено, декларируется как само совершенство... ПО написано в конце 90х, дорабатывалось дятлами, не могущими понять что делали предыдущие разработчики и ничего, работает.

Я 3 раза сталкивался со "студентами", первый раз ниасилил, требовалось переделать в многопользовательский режим некую прогу, второй и третий удачно перевел и запустил, причём второй "студент" взял меня потом на работу, правда когда ему дали отдельный кабинет с секретаршей он перестал заниматься программированием, к моему громаднейшему сожалению...

Техническим долгом надо управлять. Вот и всё.
Если им управлять - все может быть норм. Хотя может и сломаться, если "сработает" один из рисков, про который думали, что не очень вероятный.
А если не управлять - все гарантированно сломается через некоторое, обычно не очень продолжительное, время.
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130838
RIO08
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Никанор Кузьмич
Объявить- да, можно любую. ........
Технический долг - это работа, которую делать нужно, но разработчик не делает в течение некоторого времени, а откладывает на потом - то есть берет в долг у себя из будущего, фактически. Это может быть документирование, написание тестов, рефакторинг и т. п.
Вы являетесь разработчиком?
Любой человек, поступает именно так (я не исключение)!!! Есть исключения вестимо, которые подчеркивают ЭТО правило!!!

Погуглил... Долго смеялся!!! Это ж надо... А уж сколько рекламы то...

Когда то давным давно, когда деревья были большие.... Была некая "серебряная пуля" под названием "реинжиниринг". Много кто попробовал и все плевались и гнали потом "ссаными тряпками" консультантов (потом другие "пули" появились, типа Ареса (ну давно это было)), а знаете почему?
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130873
L_argo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я читал. Вы когда нить работали с SAP R3?
Меня как то убеждали, что у этой штуки, технического долга нет... Может его нет по внутренностям (движку).
Но по бизнес-процессу долга не может не быть.
Он или большой или очень большой. Особенно по коду, написанному неизвестно кем.

Как правило большой долг по документированности всех Б/П.
Мало кто знает, как внутри работает тот или иной процесс. Какие поля куда переливаются, какие модули как взаимодействуют и т.п.

Это все и приводит к невозможности или бессмысленности доработок в системе.
Долг превращается в глухой тупик.
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130906
Никанор Кузьмич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RIO08
Никанор Кузьмич
Объявить- да, можно любую. ........
Технический долг - это работа, которую делать нужно, но разработчик не делает в течение некоторого времени, а откладывает на потом - то есть берет в долг у себя из будущего, фактически. Это может быть документирование, написание тестов, рефакторинг и т. п.
Вы являетесь разработчиком?
Да, являюсь. Последние 10 лет разрабатываю на PL/SQL. На прошлом месте повезло - попал на проект, где код был покрыт тестами. Документации не было вообще (как обычно), но тестами была покрыта ключевая часть системы. Было очень удобно. Написал код, запустил тесты. Нигде ничего не упало - значит ок, скорее всего, работать будет. А если новый код как-то ломает старый, то, опять же, это видно сразу (вот прямо вообще сразу), а не через месяц, когда 100500 изменений смерджат в мастер и зальют на прод, а потом сиди разбирайся, кто виноват и что делать. На текущем проекте - каша, все кувырком, да еще и текучка. Но, по крайней мере, когда я говорю, что пишу документацию, никто не лезет с рассказми о том, что это все не нужно, и вообще "и так сойдет".

RIO08
Когда то давным давно, когда деревья были большие.... Была некая "серебряная пуля" под названием "реинжиниринг". Много кто попробовал и все плевались и гнали потом "ссаными тряпками" консультантов (потом другие "пули" появились, типа Ареса (ну давно это было)), а знаете почему?
Человек как биологический вид эволюционировал в условиях нехватки ресурсов (как, собственно, и любой другой вид). Но кроме этого, нервная система является самым большим потребителем энергии почти в любом организме, а конкретно у человека мозг, составляющий 2% от массы тела, потребляет 20% энергии. Ествественно, что человек стремится сократить до минимума расход энергии, в том числе, и на мыслительную деятельность. Отсюда и берутся все попытки найти простое и универсальное средство, которое решит все проблемы. Исторически первой областью, где люди пытались найти универсальное средство для решения всех проблем, была медицина. В древнегреческих легендах владелицей "лекарства от всего" была Панацея, дочь бога медицины Асклепия. То есть, как видите, идея универсального решения появилась как минимум одновременно с письменностью. И, скорее всего, даже намного раньше, просто следов этого не осталось. А далее, с усложнением общества и развитием технологий, человечество сталкивалось со все новыми и новыми проблемами (и даже целыми классами проблем), и, в силу тех же естественных причин, обусловленных строением мозга, не прекращались попытки найти "таблетку от всего". Надеюсь, ответил на ваш вопрос.
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130921
Фотография crutchmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RIO08,

50к хоть платят?
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130935
RIO08
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
crutchmaster
RIO08,

50к хоть платят?

Работаю за еду... Утром в ресторане кофе с булочками, днём стерлядь, запеченная в белом вине, вечером немного пива с сосисками... (у меня плебейские вкусы, пиво люблю больше вина).

Среднее по рынку.
...
Рейтинг: 0 / 0
Перспективы развития не простой системы
    #40130938
RIO08
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
L_argo

Но по бизнес-процессу долга не может не быть.

Как правило большой долг по документированности всех Б/П.
Мало кто знает, как внутри работает тот или иной процесс. Какие поля куда переливаются, какие модули как взаимодействуют и т.п.

Это все и приводит к невозможности или бессмысленности доработок в системе.
Долг превращается в глухой тупик.
Любой бизнес постоянно меняется, естественно сразу меняются и бизнес процессы. Вопрос насколько система позволяет менять эти процессы и какова трудоемкость изменений.
Сама по себе документация не значит ничего... У меня есть пример, когда задокументированная система оказалась убитой.
...
Рейтинг: 0 / 0
25 сообщений из 66, страница 2 из 3
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Перспективы развития не простой системы
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]