2017 Почемуеч поадемуоаючтуИ ТуТмдрreqcenter.pro/wp-content/uploads/pps/pps2017.pdf · и обучение персонала, в консультантов,

Практика проектирования системнаучно-образовательный журналсв. о регистрации СМИ ЭЛ №ФС77-54874 от 26 июля 2013 г

2017

www.ReqCenter.pro

Почему падают ИТ-проекты?стр 2

http://www.ReqCenter.pro

ПРАКТИКА ПРОЕКТИРОВАНИЯ СИСТЕМ 20172

Картина стабильного кризисаВ 1995 году компания The Standish Group

опубликовала первый CHAOS Report о состоянии ИТ-проектов за 1994 год [1]. Данные этого отчёта и построенные на них выводы и предсказания привели в замешательство ИТ-индустрию [15].

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

составлять 189% вызвало шок. Этот отчёт внушил ИТ-сообществу чувство кризиса, а отчёты следующих лет ещё больше укрепили его.

Результаты двадцатилетних исследований The Standish Group (см. рис.1) показывают, что доля успешных ИТ-проектов в среднем составляет 30%, а доля неуспешных и проблемных – 70% [1-9].

Рисунок 1. Статистика The Standish Group по ИТ-проектам за 1994-2015 годы

Эту картину регулярных катастроф дополняет портрет среднестатистического ИТ-проекта, который мало чем изменился с 1998 года. Он мучается от перерасхода средств на 52% и перерасхода времени на 75%,

при том, что 68% его функций, заявленных в требованиях, страдают от кривизны реализации или попросту отсутствуют [1-9].

За всеми этими цифрами стоят убытки ИТ-индустрии в сотни миллиардов долларов,

«Говорят, что числа правят миром. Нет, они только показывают, как правят миром».

Иоганн Вольфганг Гёте

Тимофеев А.Н.

Почему падают ИТ-проекты?

История - ключ к будущему. Тенденции


Опыт. Процессы. Тенденции

штрафы за проваленные проекты и судьбы миллионов людей [13-17]. И настораживает тот факт, что всё это происходит на фоне регулярных выводов о причинах кризисного состояния, рекомендаций по их устранению и прогнозов на будущее, которые публикуются в тех же отчётах The Standish Group. Но из года в год картина повторяется.

Возможно, это происходит потому, что ИТ-индустрия незнакома с этими прогнозами и рекомендациями или попросту игнорирует их? – Нет, это не так.

Результаты этих исследований навсегда вошли в историю. Именно на них из года в год ссылаются государственные, коммерческие и научные организации в своих программных документах [18-32]. Их ежегодно обсуждают и на их основе строят выводы влиятельные профильные СМИ [33-57]. Опираясь на них, государственные и коммерческие структуры обосновывают затраты на предотвращение причин кризиса. Вкладываются деньги в

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

Профильным университетам заказываются исследования. Колледжи и университеты пишут доклады и перестраивают свои программы обучения [58-62]. Работа над ошибками просто кипит по всему миру. Эти прогнозы и рекомендации хорошо известны и российскому научному сообществу [63-70].

И все же, несмотря на все усилия: культивирование «новых» методологий и вливание денег в ИТ, цифры показывают подозрительную стабильность – ежегодно только треть ИТ-проектов успешны, а остальные обновляют каталоги катастроф [71,72]. Что же происходит? В чем причины столь безрадостной картины?

Чтобы разобраться в этом, обратимся к методике и результатам двадцатилетних исследований The Standish Group.

Увлечённые другим процессом

«Легче идти вперёд, чем в нужном направлении». Михаил Генин

В бизнесе для оценки успешности применяются конкретные показатели – маяки, позволяющие корректировать курс развития бизнеса в нужную сторону. Существуют такие маяки и в ИТ-индустрии.

В 1994 году для оценки успешности ИТ-проектов The Standish Group предложила ориентироваться на три таких маяка:

• Time – срок окончания проекта;

• Budget – бюджет проекта;

• Required Features and Functions – требования заказчика к характеристикам и функциям системы.

В предложенной в этом же году методике The Standish Group составила из них следующую формулу успешного ИТ-проекта [1,12]:

on Time AND on Budget AND with Required Features and Functions (1)

С этого момента на протяжении двадцати лет ИТ-проект считался успешным, если по методике The Standish Group он: уложился в

согласованные заказчиком и исполнителем срок (on Time) И не перерасходовал первоначальный бюджет (on Budget) И в нем были реализованы согласованные с заказчиком



требования к характеристикам и функциям системы (with Required Features and Functions).

К проблемным относились проекты, которые были завершены и работали, но были выполнены с перерасходом времени или бюджета и с меньшим, чем требовалось, числом свойств и функций.

К неуспешным – проекты, отменённые до их завершения или выполненные, но так и не введённые в эксплуатацию.

Многократные исследования самой методики The Standish Group, проведённые научным сообществом, выявили в ней ряд серьёзных недостатков [100-109]. Основным из них считают игнорирование зависимости времени и бюджета от изменений в требованиях. При таком подходе проекты с полностью реализованными требованиями, но даже с небольшим перерасходом времени или бюджета попадали в разряд проблемных, хотя итоговый результат полностью устраивал заказчика. «Железный треугольник» PMI оказался разорван.

В тоже время отчёты Standish Group показывали, что успех любого ИТ-проекта определяют три взаимозависимых фактора [1-10,75]:

• Поддержка проекта высшим руководством.

• Вовлечение пользователей в проект.

• Ясные цели бизнеса.

Отсюда в отчётах The Standish Group все эти годы фигурировал один и тот же вывод [1-10, 75]: «Те проекты успешны, которые поддерживаются высшим руководством заказчика, ясно понимающим цели бизнеса. Это обеспечивает своевременное выявление и вовлечение их ключевых сотрудников в процесс создания ИТ-системы и в итоге приводит к

ясным и чётким требованиям к функциям и характеристикам ИТ-системы, необходимым для достижения именно этих целей бизнеса».

И поэтому исследователи из The Standish Group постоянно рекомендовали уделять особое внимание организации взаимодействия исполнителей с владельцами бизнеса, руководителями организаций и конечными пользователями – основными идеологами целей создания систем и поставщиками требований к ним [7-9].

Эти рекомендации поддерживали и другие исследователи [73-84,86]. По их общему мнению своевременное и правильное определение целей заказчика – это основа успеха проекта. Цели бизнеса – это основополагающие требования, то ради чего и создаётся система и относительно чего и должны формироваться требования к ней.

Однако, несмотря на столь очевидную зависимость времени и бюджета от целей, они до недавнего времени не входили в формулу успеха The Standish Group, хотя и «маячили» постоянно в факторах успеха.

Положение дел изменилось в 2014 году, когда The Standish Group провели повторное исследование успешных проектов из базы предыдущих лет. Результаты этого исследования показали, что успешные проекты с плохо проработанными целями заказчика породили системы, которые в итоге не дали заказчику нужных результатов и потому быстро завершили свой жизненный цикл, хотя и полностью соответствовали формуле успеха (1) [12,99].

Игнорировать такие результаты The Standish Group не могла и в 2015 году предложила ориентироваться на новую формулу успеха:

on Time, on Budget, on Target, on Goal, Value and Satisfaction (2)

По замыслу авторов эта новая формула с шестью переменными показывает

необходимость достижения проектами установленных требований (on Target),



соответствующих целям заказчика (on Goal). При этом проект будет считаться успешным, если заказчик получит от созданной системы не только необходимые ценности (Value), но и выразит удовлетворённость (Satisfaction) организацией и выполнением исполнителем работ, а также их результатами [12,14].

Но изменит ли что-то появление целей бизнеса в формуле успеха? Следует ли ожидать кардинальных изменений в картине кризиса? – И да, и нет.

Безусловно, картина кризиса станет точнее. Это уже показал пересчёт результатов исследований за 2011-2014 годы, выполненный The Standish Group по новой формуле –

количество успешных проектов уменьшилось на 7-12% [12].

Но поскольку маяк в виде «целей бизнеса» все равно постоянно светился в факторах успеха и рекомендациях, то игры с формулами не смогут изменить реальное положение дел в ИТ-индустрии. «Бессмысленно продолжать делать то же самое и ждать других результатов» –как отметил Альберт Эйнштейн.

Но тогда в чем же дело? Что тогда мешает успеху ИТ-проектов и приводит к неизменной картине кризиса?

Фактор Х

«Умение обращаться с людьми — это товар, который можно купить точно так же, как мы покупаем сахар или кофе.

И заплатят за такое умение больше, чем за что-либо другое на свете». Джон Рокфеллер

На первый взгляд нет ничего сложного в реализации каждого из трёх условий, обеспечивающих успех проекта. Ну что сложного в том, чтобы обеспечить поддержку проекта со стороны владельцев бизнеса и руководителей организации заказчика? В чем сложность вовлечения пользователей и их руководителей в процесс создания системы? И вообще, какие проблемы могут быть с определением целей и требований? Ведь все это нужно самому заказчику! Не так ли?

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

покушение на их образ жизни в организации, потеря власти или даже потеря работы. Другим автоматизация безразлична. А третьим она может принести серьёзные карьерные выгоды и иные бонусы.

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

Он пришёл в мир ИТ в начале 70 годов прошлого века из мира промышленного производства товаров и хорошо знаком не одному поколению разработчиков ПО [87]. В нем нет ничего ни от одной из методологий разработки ПО. Он и его собратья в шуточном



стиле отражают результаты нешуточной проблемы взаимопонимания между людьми. В её основе лежит уверенность большинства людей в том, что они от рождения обладают даром ясно объяснять и понимать других людей. Но человек далеко не всегда понимает даже себя самого и далеко не всегда открыт для общения [89]. И вот что говорят результаты исследований общения людей [88-94]:

1. Люди исходно имеют когнитивные ограничения, которые исключают полное взаимопонимание. У каждого человека есть своё представление об окружающем мире, сформированное в ходе взаимодействия его уникальной психики с тем, что его окружает. Одно и то же событие воспринимаются людьми по-разному. Его интерпретация зависит от физического и психического состояния человека в момент события, его знаний, культуры и предыдущего опыта.

2. Взаимоотношения человека с окружающим миром находятся под контролем эмоционального интеллекта, стоящего на страже его безопасности. По скорости реакции он всегда опережает рациональное мышление и потому реальный контакт между людьми начинается намного раньше, чем произнесено первое слово. Люди в буквальном смысле встречают друг друга «по одёжке» и готовность человека к общению сильно зависит от реакций его эмоционального интеллекта.

3. Общение по необходимости сильно отличается от общения для удовольствия – для человека нет ничего хуже навязанного общения.

4. Используемые человеком слова довольно абстрактны. За «хорошо», «плохо», «красиво» стоят разные представления людей о доброте, зле и красоте. Построенные на них фразы не несут никакого смысла, пока определены точные значения входящих в них



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

5. В любом мероприятии каждый человек преследует свои цели. Цели конкретного человека в конкретных обстоятельствах могут совпадать с целями других людей, а могут и противоречить. Конфликты интересов сопровождают любую совместную деятельность.

Выявление ясных и чётких целей бизнеса и производных от них требований требует прямого общения с их поставщиками, т.е., вовлечения их в процесс проектирования. А для этого необходимо создание в проекте среды общения, способствующей психологической адаптации разных людей к совместной деятельности. Для этого нужны знания и умения в области психологии личности, психологии отношений, психологии восприятия, психологии среды, конфликтологии и т.д. И владение ими просто необходимо таким специалистам, как бизнесаналитики, так как их психологическая безграмотность в вербальном и невербальном общении с людьми способна разрушить любой проект в самом его начале.

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

Вот что, например, пишет некая Тоня Смит в комментариях к статье «Что я должен изучать в колледже, чтобы стать бизнес-аналитиком?» [95]:

«Получая диплом бакалавра, я перешла с профильного направления «Психология» на «Социальное обеспечение», и я нахожу, что

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

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

«Извлечение неявных ожиданий из голов стейкхолдеров требует навыков, которыми, как правило, обладают психологи, а именно: внимательное и полное выявление, сопереживание, понимание и выслушивание. Бизнес-аналитики, по крайней мере, должны быть немного психологами в своём деле, чтобы делать свою работу успешно» - пишет Стив Блейс в статье «Бизнес-аналитик как терапевт», указывая на то, что выявление скрытых ожиданий владельцев бизнеса от реализации ИТ-проекта во многом определяет его успех [96].

Также много общего и между бизнес-аналитиком и журналистом – и тот и другой занимаются интенсивным общением с людьми в целях сбора и анализа фактов. Разница опять в том, что профессиональная подготовка журналистов предусматривает не только изучение логики, но и общей психологии и психологии своей специальности – журналистики. Примечательно, что в их подготовку обязательно входят психологическая экспертиза текстов,



психология общения и методы психологической защиты.

Очевидно, что индустрия ИТ остро нуждается в профессионально подготовленных бизнес-аналитиках, мастерски владеющих инструментами психологии. Сегодня такая подготовка является необходимым условием успеха проектов – тем самым фактором Х, который даёт серьёзные конкурентные преимущества. Об этом говорят результаты исследований организации «Всемирный банк», в которых утверждается, что дефицит социальных и поведенческих компетенций среди сотрудников компаний является одним из самых серьёзных факторов, ограничивающих развитие и рост этих компаний [97]. И хотя ещё не так много учебных заведений, которые по примеру Western Technical College включили психологию в программу подготовки бизнес-аналитиков – начало положено [98].

Доказано также, что компетенции в области психологии нужны не только бизнес-аналитикам: исследования The Standish Group указывают на недостаток таких компетенций у исполнительного руководства со стороны бизнеса и их прямую связь с неудачами проектов [8].

Сегодня компании только начинают это осознавать. И конкурентные преимущества будут у тех и них, кто раньше начнёт вкладывать в психологическую подготовку кадров. Ведь стабильная картина кризиса в течение двадцати лет показывает, что только 3 из 10 проектов управляются людьми, которые искусно владеют фактором Х.

Литература1. The Standish Group Report, 1994

2. Chaos: A Recipe for Success, tech. report. The Standish Group International, Inc., 1999

3. Extreme CHAOS. The Standish Group International, Inc., 2001.

4. CHAOS - The state of the software industry. The Standish Group International, Inc., 2003.

5. CHAOS Summary. The Standish Group International, Inc., 2009.

6. CHAOS Summary. The Standish Group International, Inc., 2010.

7. CHAOS MANIFESTO. The Standish Group International, Inc., 2011.



10. Big Bang Boom. The Standish Group International, Inc.,2014.

11. Law of the Five Deadly Sins. The Standish Group International, Inc.,2014.

12. Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch. https://www.infoq.com/articles/standish-chaos-2015.

13. David F. Rico. Global Project Failures. http://davidfrico.com/project-failures.pdf - 2010.

14. Paul Summers. 98.8%! Is project failure acceptable and inevitable? – 2015.

15. Colin Ellis. Why half your projects will fail this year/ http://www.cio.com.au/article/582055/why-half-your-projects-will-fail-year/ – 2015.

16. С. Попсулин, «HP заплатит многомиллионный штраф за срыв госконтракта», Cnews, 2015.

17. Benoit Hardy-Vallee. The Cost of Bad Project Management. http://www.gallup.com/businessjournal/152429/cost-bad-management.aspx#1 -2012.

18. Parliamentary Office of Science and Technology, «Government IT projects». Report 200, London, POST, 2003.

19. Department of Economic and Social Affairs, «World Public Sector Report 2003: E-Government at the Crossroads», United Nations, New York, 2003

20. Kanton Basel-Landschaft, «Wie steht es mit der EDV im Kanton wirklich?», 2002

21. FERC Staff Report on PSO Information Technology Guidelines.2005

22. National Association of State Chief Information Officers (NASCIO), «DISCIPLINE SUCCEEDS: Findings from the


NASCIO State IT Project Management Assessment»,2005

23. OECD E-Government Project. BENEFITS REALISATION MANAGEMENT. GOV/PGC/EGOV(2006)11/REV1. 2007

24. KPMG «Government IT Projects Need QA/IV&V. The why and how of Quality Assurance/Independent Verification and Validation», 2009.

25. RCMP Canadian Firearms Program. Program Evaluation. Final Approved Report, Finding 9, 2010

26. KPMG, «Portfolio, Programme and Project Management (P3M) Capabilities in Gvernment, Increasing Success Rates and Reducing Costs», New Zealand, 2011

27. «A Critical Assessment of P3M3 in Australian Federal Government Agencies», 2011.

28. Office of the Chief Information Officer, «Common Causes for Failure in Major ICT-enabled Programs and Projects», Government of South Australia 2012.

29. Raj Shah, Vice President, Sapient Government Services, «Adapting Agile for Government IT Development. Sapient Delivers a Scalable and Repeatable Process», Sapient Corporation, 2013.

30. STATEMENT OF KAREN S. EVANS FORMER ADMINISTRATOR FOR ELECTRONIC GOVERNMENT AND INFORMATION TECHNOLOGY OFFICE OF MANAGEMENT AND BUDGET BEFORE THE COMMITTEE ON HOMELAND SECURITY AND GOVERNMENTAL AFFAIRS, May 8, 2014

31. «Study on e-Government and the Reduction of Administrative Burden», Final Report By the European Commission, Directorate-General of Communications Networks, Content & Technology, 2014.

32. «Agile Software Development. Pursuit for Agile in Government», Booz Allen Hamilton, Inc., 2014

33. K.T. Yeo, «Critical failure factors in information system projects», International Journal of Project Management 20 (2002) 241–246.

34. Carr, N.G. , «IT Doesn’t Matter», Harvard Business Review, May 2003.

35. Ahmet D., «The Challenge of Large-Scale IT Projects», International Journal of Social, Behavioral, Educational, Economic and Management Engineering Vol:1, No:9, 2007.

36. Svetlana C., Damian H, «New Possibilities For Project Management Theory: A Critical Engagement», PROJECT MANAGEMENT JOURNAL 2006.

37. Byron Connolly, «Top 10 enterprise IT disasters», CIO, 2014.

38. David Taber, «3 Good Ideas From Government Software Projects», CIO,2014.

39. William Allassani, «THE IMPACT OF IT GOVERNANCE ON IT PROJECTS -THE CASE OF THE GHANA RURAL BANK COMPUTERIZATION

AND INTER-CONNECTIVITY PROJECT», Journal of Information Systems and Technology Management Vol. 10, No. 2, May/Aug., 2013, pp.271-286.

40. Tod Newcombe, «Can Government Avoid Technology Failure?», GOVERNING , 2014.

41. Roger Baker, «How CIOs can use FITARA to get away from waterfall», FCW. Jan 30, 2015.

42. Jim Ditmore, «Why Do Big IT Projects Fail So Often?», InformationWeek, 2013.

43. Adanma Cecilia Eberendu «Evaluation of Software Project Failure and Abandonment in Tertiary Institutions in Nigeria», Information and Knowledge Management Vol.5, No.4, 2015

44. Prof. Dr. Adel Darwish, Assoc. Prof. Dr. Ayman E. Khedr, Dr. Iman Asaad Badr, Mr. Ahmed Fouad Omran. «Proposed a Structured Framework for Enhancing Software Projects Quality», International Journal of Computer Science and Software Engineering (IJCSSE), Volume 4, Issue 1, January 2015

45. Steve Dr Freeman, «Standish Group survey», The Financial Times Ltd, 2006

46. Graham Oakes, «There’s no success like failure...», The Financial Times Ltd, 2006

47. Jean-Claude Ramirez and Steve Berez, «Beating Scope Creep, the Scourge of IT Projects», THE WALL STREET JOURNAL, 2012

48. Benoit Hardy-Vallee, «The Cost of Bad Project Management», Gallup, 2012.

49. Flyvbjerg, B. and Budzier, A., «Why Your IT Project May Be Riskier Than You Think», Harvard Business Review, September 2011.

50. «Pulse of the Profession: Requirements Management — A Core Competency for Project and Program Success», PMI, August 2014

51. «Modern Requirements Management (MRM):The Data don’t Lie», Jama Software Inc., 2015

52. Niam Yaraghi , «Doomed: Challenges and solutions to government IT projects», The Brookings Institution, 2015

53. Dexter Whitfield,«Cost overruns, delays and terminations: 105 outsourced public sector ICT projects», ESSU Research Report No. 3,2007.

54. «OMB and Agencies Need to Improve Planning, Management, and Oversight of Projects Totaling Billions of Dollars», Statement of David A. Powner Director, Information Technology Management Issues, GAO, 2009

55. Ian Needs,«Why PMOs Fail: 5 Shocking PMO Statistics»,KeyedIn Solutions, Inc, 2014.

56. Steve Hendershot, «Facing Up to Government IT Project Failures», Project Management Institute, Inc., 2015.

57. David Francis, «Federal IT Flaws Go Well Beyond Obamacare», The Fiscal Times, 2013.


58. Jack T. Marchewka, «The FBI Virtual Case File: A Case Study», Communications of the IIMA Volume 10 Issue 2, 2010.

59. M Bronte-Stewart «Developing a risk estimation model from IT project failure research», School of Computing, University of Paisley.

60. Rupinder Kaur, Dr. Jyotsna Sengupta «Software Process Models and Analysis on Failure of Software Development Projects», International Journal of Scientific & Engineering Research Volume 2, Issue 2, February-2011.

61. A.M. Al-Khouri,Warwick University, «A Methodology for Managing Large-Scale IT Projects», Warwick Eng Conference, 2007

62. Putnam P. Texel, «Exploring Government Contractor Experiences Assessing and Reporting Software Development Status», Walden University, 2015.

63. И.Р. Мавлявиев. Роль систем управления задачами при разработке проектов. Современные проблемы и тенденции развития экономики и управления. Сборник статей Международной научно-практической конференции. НИЦ «АЭТЕРНА», Екатеринбург - 2016.

64. Николаенко В.С. Анализ инструментария по обеспечению функции управления рисками в ИТ-проектах. Сетевой научный журнал «Государственное управление. Электронный вестник». Выпуск № 49. Апрель 2015 г. Факультет государственного управления МГУ имени М.В.Ломоносова, 2015.

65. I.V. Koverninskiy, A.V. Kan, V.B. Volko, Yu. S. Popov, N.K. Gorelits. Practical experience of software and system engineering approaches in requirements management for software development in aviation industry.Труды Института системного программирования РАН. Том 28, выпуск 2. Москва, 2016.

66. И.В. Катунина, Ю.А. Фомина. Офис управления проектами улучшения городской среды в городе Омске. ВЕСТНИК ОМСКОГО УНИВЕРСИТЕТА. Серия «ЭКОНОМИКА», № 3, 2016.

67. О.Е. Масленникова. Типовой проект внедрения корпоративной информационной системы на крупное промышленное предприятие. Материалы 73-й международной научно-технической конференции «Актуальные проблемы современной науки, техники и образования». Том 2. Под. Ред. В.М. Колокольцева. Магнитогорск, 2015.

68. Каширина Н. В., Маран М. М. Сопоставительный анализ подготовки специалистов по информационным технологиям в вузах России и за рубежом. Интернет-журнал «НАУКОВЕДЕНИЕ». Том 7, №3 (май - июнь 2015).

69. В.Е. Гвоздев, Д,в. Блинова, Л.Р. Черняховская. Предупреждение дефектов на ранних стадиях проектирования аппаратно-программных комплексов на основе положений теории интерсубъективного управления. Научный журнал «Онтология

проектирования». Том 6, №4(22), 2016.

70. Ломазов В.А., Ломазова В.И., Нехотина В.С. Поддержка принятия решений при оценивании ит-проектов. Академия естествознания. Международный журнал прикладных и фундаментальных исследований. №3, 2015.

71. Software Fail Watch 2016, Quarter One. http://www.tricentis.com/blog/2016/04/07/software-fail-watch-2016-quarter-one/ - 2016.

72. Top software failures 2015/2016: Amazon, RBS, Starbucks - the worst software glitches this year. http://www.computerworlduk.com/galleries/infrastructure/top-10-software-failures-of-2014-3599618/.- 2016.

73. Aberdeen Group. The Talent Acquisition Lifecycle: From Sourcing to Onboarding. -2011.

74. Aberdeen Group. The Business of First Impressions. -2012.

75. ESP Solutions Group. Why 70% of Government IT Projects Fail – Quality Project Managementfor Education Agencies, Project Management Series – Part I, 2nd Edition. - 2009.

76. Michael Bloch, Sven Blumberg, and Jürgen Laartz. Delivering large-scale IT projects on time, on budget, and on value.- 2012.

77. Why a Majority of Business and IT Teams Anticipate Their Software Development Projects Will Fail. https://www.geneca.com/case-study-aligning-business-and-it-on-project-definition-and-development-getting-predictable-0 - 2011.

78. Rupinder Kaur, Dr. Jyotsna Sengupta. Software Process Models and Analysis on Failure of Software Development Projects. International Journal of Scientific & Engineering Research Volume 2, Issue 2, 2011

79. Dr. Roslina Ibrahim,Erfan Ayazi ,Shahab Nasrmalek ,Shamin Nakhat.An Investigation of Critical Failure Factors In Information Technology Projects. IOSR Journal of Business and Management, Volume 10, Issue 3), PP 87-92ю – 2013.

80. Divya P. Velayudhan, Dr. Sam Thomas. Measuring Project Success: Emergence of Dimensions. The International Journal Of Business & Management. Vol 4, Issue 4, 2016

81. Rubens M. Faro Pompeu, Selma Regina Martins de Oliveira. Critical Success Factors in IT Projects: An Exploratory Survey. International Journal of Innovative Research in Science, Engineering and Technology. Vol. 4, Issue 11, November 2015

82. David J. Laird . The impact of planning and other organizational factors on the success of small information technology projects. University of Pittsburgh – 2016.

83. Mark Harwardt. Criteria of Successful IT Projects from Management's Perspective. Open Journal of Information Systems (OJIS).Volume 3, Issue 1, 2016.


84. Marko Yli-Pietilä, Lauri Eskola. Business Benefits Realization. Midagon – 2016.

85. PMI. PMI’s Pulse of the Profession: Requirements Management — A Core Competency for Project and Program Success.- 2014.

86. PMI. PMI’s Pulse of the Profession. The High Cost of Low Performance. How will you improve business results? 8th Global Project Management Survey– 2016.

87. Tree swing pictures. http://www.businessballs.com/treeswing.htm

88. Davey, B., & Parker, K. Requirements elicitation problems: A literature analysis. Issues in Informing Science and Information Technology, 12, 71-82. 2015

89. Эрик Берн. Игры, в которые играют люди. Люди, которые играют в игры Эксмо 2008

90. J. Hawkins, S.Blakeslee. On Intelligence. TimesBooks, Ney York, 2004.

91. Д.Гоулман. Эмоциональный интеллект. Почему он значит больше чем IQ. Манн, Иванов и Фербер. 2016.

92. Рита Картер. Как работает мозг. АСТ, Corpus 2014.

93. Дэвид Майерс. Психология. Попури: 2008

94. Дэвид Майерс. Социальная психология в модулях Прайм-Еврознак, Харвест 2006

95. Laura Brandenburg. What Should I Study in College to Become a Business Analyst?http://www.bridging-the-gap.com/help-a-ba-what-should-i-study-in-college-to-become-a-business-analyst/#comment-12275. - 2012.

96. Steve Blais. The Business Analyst as Therapist. https://www.batimes.com/steve-blais/the-business-analyst-as-therapist.html. – 2012

97. Всемирный банк. Комплексное диагностическое исследование экономики Российской Федерации: пути достижения всеобъемлющего экономического роста. - 2016.

98. Western Technical College. Business Analyst program. https://next.westerntc.edu/wp-content/uploads/2016/05/Business-Analyst-Flyer-P1.pdf. – 2015.

99. Success Redefined. The Standish Group International, Inc. http://blog.standishgroup.com/post/23

100. N. Zvegintzov, «Frequently Begged Questions and How to Answer Them», IEEE Software, vol. 20, no. 2, 1998, pp. 93–96.

101. C. Jones, «Project Management Tools and Software Failures and Successes», Crosstalk, July 1998, pp. 13–17.

102. C. Sauer and C. Cuthbertson, «The State of IT Project Management in the UK 2002–2003», Computer Weekly, 15 Apr. 2003.

103. Magne Jørgensen, Kjetil Moløkken-Østvol, «How large are software cost overruns? A review of the 1994 CHAOS report», Information and Software Technology. 2005

104. R. Glass. «The Standish Report: Does It Really Describe a Software Crisis?» Communications Of The ACM, Vol. 49, No. 8, August 2006.

105. Chris Sauer, Andrew Gemino, Blaize Horner Reich. «The impact of size and volatility on it project performance», COMMUNICATIONS OF THE ACM, November 2007.

106. Michael Krigsman. New IT project failure metrics: is Standish wrong? http://www.zdnet.com/article/new-it-project-failure-metrics-is-standish-wrong/ - December 2007.

107. Khaled El Emam, A. Gunesё Koru «A Replicated Survey of IT Software Project Failures», IEEE Software, 2008.

108. J. Laurenz Eveleens and Chris Verhoef, Vrije Universiteit Amsterdam. The Rise and Fall of the Chaos Report Figures. IEEE Software, 2010.

109. Dirk Basten, Oleg Pankratz, Dominik Joosten.«Assessing the assessors – an overview and evaluation of it project success reports». Proceedings of the 21st European Conference on Information Systems. 2013.


Об авторе

Тимофеев Алексей НиколаевичГенеральный директор ООО «САТУРС», к.т.н..

Более 35 лет успешного опыта ведения сложных ИТ-проектов. Специалист высшей квалификации в области проектирования и разработки программно-технических систем. Руководил коллективами от 3 до 400 специалистов иглубоко понимает все особенности проектов по созданию программного обеспечения.

Имеет несколько десятков сертификатов в области программной инженерии.

Ведёт работу и консультирует по направлениям:• Организация системного проектирования и управления проектами по созданию программно-

технических систем.

• Методологии разработки разработки программного обеспечения.

• Проектирование автоматизированных систем.

• Создание команд и управление ими.

Связаться с автором можно по e-mail [email protected] или через linkedin

https://www.linkedin.com/in/aleksey-timofeev-0315704b/en

3SL Cradleсистемная инженерия

УПРА

ВЛЕН

ИЕ

ДО

КУМ

ЕНТА

МИ

до создания!От концепции

Колыбель проектирования

Входящиедокументы

Исходящиедокументы

Интеграция с MS Project

Стратегическоеуправление

Оперативноеуправление

УП

РАВ

ЛЕН

ИЕ

ПРО

ЕКТО

М

метрики и KPI Приоритеты и статусы

Графики освоенного объемаУчет и оценка влияния

Отслеживание рисков - статусы, метрики

Авторазбор

Управление версиями

Генерация документов любой структуры

Управление версиями

Уровни секретности и контроль доступа

Разработкатребований

Моделирование и анализ

Управлениеизменениями

Любые форматы Конфигурационное управление

Оценка влияния изменений С

ИСТЕ

МНО

Е ПР

ОЕК

ТИРО

ВАНИ

Е

UML, SysML, IDEF0, ER и др.

Свозная трассировка

ЭргономикаСквозная трассировка

к требованиям

Сквозная трассировка к проектным данным

Сквозная трассировка к проектным данным

Контроль качества и сроковПоддержка любой

проектной методологииСквозная трассировка

к требованиям и задачам

Управлениерисками

На

прав

ах р

екла

мы

Documents

2017 Почемуеч поадемуоаючтуИ ТуТмдрreqcenter.pro/wp-content/uploads/pps/pps2017.pdf · и обучение персонала, в консультантов,