Базовые знания и навыки

Назначение

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

• Умение решать задачи.
• Аналитический склад ума.
• Упорство.
• Хорошая концентрация.
• Усидчивость.
• Алгоритмизированный подход.
• Ответственность.
• Инициативность.
• Коммуникабельность.
• Умение работать в команде.

И вот тут-то и появляются первые вопросы и противоречия. Часть этих качеств свойственна людям, которые по типу темперамента относятся к интровертам ("завернутым в себя", стремящимся к минимизации контактов с вешним миром), а другая часть — к экстравертам ("повернутым к миру", стремящимся к контакту с социумом). Это говорит о том, что программный инженер должен стремиться не только к комплексному профессиональному развитию, но и к развитию своих личностных качеств, — иными словами, к тому, чтобы стать более разносторонней личностью.

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

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

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

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

Готовность к обучению, самообучению, исследованию нового

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

Умение и желание адаптироваться к окружающим условиям

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

Увлечение работой

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

Соблюдение принятых стандартов

В своей профессиональной деятельности нужно постоянно учиться находить золотую середину (для каждого проекта и продукта она своя) между "сделал как получится" и "создал самый совершенный продукт".

В каждом проекте, в каждом продукте есть свои условия и ресурсы, необходимые для решения поставленной задачи. Необходимо, отталкиваясь от них, уметь определять допустимое качество продукта.

Анализ, декомпозиция Проектирование, агрегирование

Об этом мы уже говорили в прошлой главе, но вы должны понимать, что эти рабочие принципы будут требоваться от вас каждый день в различных активностях. Получив задачу, программный инженер не должен сразу бежать создавать код. Он 80% времени работает головой, и только 20% — руками. Создание не очень сложной пользовательской программы задействует все те необходимые качества, о которых мы подробно будем говорить дальше. Тут на первый план выходят основательный анализ и корректная декомпозиция — во многом они составляют ядро инженерной работы.

Оценка задач

"Для решения этой задачи мне потребуется 8 часов" — это непрофессиональный ответ. Время решения задачи — величина вероятностная. Интервальный ответ всегда будет более корректным: "От 4 (быстрее точно не смогу) до 16 часов (скорее всего, точно сделаю)".

Большой разброс оценок не должен смущать руководителя — он отражает высокий уровень неопределенности при решении задач, которые довольно редко бывают полностью понятны и прозрачны.

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

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

Тестирование, ревью и отладка

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

"Откомпилировалось – отправляем на тестирование!" — подход непрофессиональный. Профессионал обязан найти максимум ошибок в своей работе. Большинство ошибок лежит на границах областей определения и изменения переменных выбранного алгоритма.

Ищите причины дефектов, решайте возникшие проблемы, преодолевайте неудачи

Программный инженер должен обеспечивать обратную связь — как со своим окружением, так и со своим продуктом. Рассматривайте отклонения — от намеченных планов, качества, выявляйте их причины, чтобы скорректировать дальнейший рабочий процесс, — и минимизируйте их. Если у вас нет опыта создания приложения с нуля, то это станет для вас сложной задачей. Хороший специалист всегда будет искать способы выполнить работу несмотря ни на что. В противном случае фраза "Это невозможно" станет вашим лозунгом. Дело в том, что профессионалов, которые реализуют свою идею с первой попытки и без ошибок, просто не существует — все сталкиваются с трудностями в решении поставленных задач. Важно, чтобы подобрался такой коллектив, который в ошибках и недочетах будет видеть в первую очередь вызов и возможность стать лучше.

Навыки общения и понимание специфики деятельности, для которой выполняется автоматизация

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

Работа в команде

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

Английский язык

В число навыков, которыми необходимо обладать каждому IT-специалисту, входит знание английского языка. Он, так уж сложилось исторически, является наиболее распространенным и используемым языком нашей планеты, немного уступая в численности носителей китайскому языку. Но китайский не может конкурировать с английским языком в силу своего "закрытого" окружения и специфики.

Знание английского языка — важный аспект успешной карьеры программного инженера.

Английский в сфере IT — актив. Он позволяет обсуждать сложные рабочие процедуры и эффективно общаться на рабочем месте.

Многонациональные технологические компании, работать в которых стремится большинство квалифицированных инженеров, — Apple, Hewlett-Packard, Amazon, Microsoft, Google, Intel, Cisco Systems и многие другие — выбирают английский в качестве корпоративного языка, чтобы облегчить общение и повысить производительность в разных географических регионах и деловых проектах.

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

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

IT — это быстро развивающаяся отрасль, в которой постоянно создаются и выпускаются новые устройства, программы, приложения, фреймворки. Все языки программирования основаны на английской лексике, и знание ее во многом является фундаментальным базисом.

Еще одна, возможно, немного неожиданная причина для изучения английского языка — хорошая память, которая работнику в IT-сфере просто необходима.

Существуют свидетельства, что изучение иностранного языка может защитить мозг от деградации по мере взросления. Некоторые виды деменции (mental debility) диагностируются на 5 лет позже у тех людей, которые знают более одного языка, по сравнению с теми, которые говорят только на одном. Не правда ли, еще один прекрасный стимул освоить английский язык?

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

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

Десятипальцевый метод печати

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

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

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

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

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

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

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

Постепенно, шаг за шагом, вы перестанете при печати поглядывать на клавиатуру, а главное, навык будет закрепляться, а скорость набора — расти. Потребность же смотреть на клавиатуру со временем ослабеет, а потом пропадет совсем.

Итак, выберите подходящую вам схему — и начитайте обучение слепому методу печати. Вот ряд советов, которые при этом будут вам полезны:

1. Каждый раз, когда вы приступаете к набору текста, нащупывайте указательными пальцами риски на клавишах F/А и J/О. Они предназначены для того, чтобы помогать вам правильно класть пальцы на клавиатуру, не глядя на нее.
2. Установите клавиатуру так, чтобы руки на ней располагались симметрично вашему телу, а не были смещены влево или вправо. Центр основной части клавиатуры находится между клавишами G/П и H/Р.
3. Старайтесь не смотреть на клавиатуру. Должна работать не зрительная память, а пальцы. Всю печатную работу выполняет мышечная память, используя тактильные ощущения пальцев. Если они запомнят расположение клавиш, печатать будет гораздо проще.
4. Магическая формулировка ФЫВА ОЛДЖ. Держите руки в правильной позиции: левую (мизинец, безымянный, средний и указательный) на буквах ФЫВА, правую — на ОЛДЖ.
5. Большие пальцы должны нажимать на пробел поочередно. То есть если последнюю клавишу (букву, знак в предложении) вы нажали левой рукой, то и на пробел нажимает большой палец левой руки — и наоборот. В "период покоя" большие пальцы зависают в воздухе над клавишей пробела.
6. Нажатие клавиши производится ближайшим пальцем, при нажатии смещается только один палец, после чего он возвращается в начальную позицию. Таким же образом печатаются и заглавные буквы, однако при этом мизинец свободной руки удерживает зажатой клавишу Shift.
7. Не ставьте перед собой цель держать в памяти, где какая буква расположена на клавиатуре. Главное — запомнить, каким пальцем и какое движение нужно сделать, чтобы набрать нужный символ. В своем подсознании вы должны соединить движения пальцев с определенной буквой.

Лучшие практики и целостная картина

В этой главе мы уже говорили об основных базовых навыках, развитие которых предоставит начинающему программному инженеру определенную свободу и возможности более быстрой самореализации по сравнению с коллегами, которые не будут:

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

Далее по ходу курса мы еще не раз будем говорить о различных аспектах программной инженерии. А сейчас более детально и обстоятельно расскажем о лучших практиках, каждая из которых зафиксирована в определенном своде знаний, или Body of Knowledge (BOK).

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

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

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

Сфера программной инженерии содержит множество различных активностей, каждая из которых имеет свой BOK:

• Бизнес-анализ (BA)
  • Работа со стейкхолдерами.
  • Поиск вариантов решения бизнес-проблем.
  • Технико-экономическое обоснование и приоритизация работ.
  • Работа над рамками возможности/проблемы.
  • Инженерия требований

и т. д.

• Системный анализ (SA)
  • Формализация и представление требований.
  • Создание успешной системы в рамках заданных ограничений

и т. д.

• Разработка программного обеспечения (Dev)
  • Об этом нужно говорить отдельно и достаточно обстоятельно.
• Тестирование (Test)
  • Ручное тестирование.
  • Автотестирование.
  • Интеграционное тестирование

и т. д.

• Внедрение и эксплуатация программного обеспечения (ITIL)
  • Разворачивание IT-системы.
  • Эксплуатация и сопровождение системы.
• Архитектура программного обеспечения (ARCH)
  • Бизнес-архитектура системы.
  • IT-архитектура системы.
• IT-безопасность (Security)
  • Вопросы информационной безопасности используемых систем.
• IT-менеджмент (IT Management)
  • Методология и организация IT-процессов компании.
  • Эффективные подходы к разработке и сопровождению продуктов.

Эти активности представлены на рис. 3.1 рис. 3.1. Каждое направление разбивается еще на ряд активностей.

увеличить изображение
Рис. 3.1.

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

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

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

Любая активность, как правило, имеет несколько BOK, каждый из которых описывает отдельные представления определенной профессиональной сферы. Если в информационном мире начинает уделяться особое внимание конкретному вопросу, то для этой активности пишется отдельный BOK, как, например, произошло с областью исследования и работы с данными. Первоначально находящийся в рамках BABOK, этот аспект выделился в DAMA DMBOK, расширился и дополнился специфичными и инструментальными деталями, необходимыми для развития этого направления.

Обсудим BOK более конкретно и обстоятельно.

Бизнес-анализ

Область бизнес-анализа (рис. 3.2 рис. 3.2) отвечает за формирование основной идеи, которая после ее реализации должна приносить значимые выгоды. На бизнес-аналитиках лежат обязанности по:

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

Рис. 3.2.

О каждой из перечисленных обязанностей может быть написана отдельная книга, но мы ограничимся описанием следующих BOK:

• BABOK
  • Этот BOK сконцентрирован на описании того, как выстроить взаимоотношения с заказчиком, на инженерии требований и их жизненном цикле применительно к организации, стратегическом анализе, определении вариантов решений и их последующей оценке.
  • На текущий момент существует уже 3-я версия этого BOK.
• BPM CBOK
  • В нем представлен взгляд на организацию как структуру взаимосвязанных процессов. Этот BOK описывает, в чем состоит суть процессной деятельности и каким образом ее следует выстраивать и развивать применительно к реалиям конкретной организации.
  • Существует уже 3-я версия этого BOK.
• BRMBOK
  • Это свод знаний о том, как необходимо выстраивать взаимоотношения между бизнесом и IT, чтобы эти взаимоотношения приносили максимальную выгоду руководству компании.
  • Труд только начал развиваться. Активно формируется и дополняется.
• BIBOK
  • Что необходимо делать для того, чтобы извлекать максимальную выгоду из имеющихся в организации данных.
  • Этот BOK только начал развиваться. Активно формируется и дополняется.
• DAMA DMBOK
  • Что необходимо делать для того, чтобы структурировать и упростить работу с данными компании, какая должна быть создана инфраструктура поставки данных, чтобы их ценность была понятна и очевидна.
  • Существует уже 3-я версия этого BOK.

Системный анализ

Системный анализ (рис. 3.3 рис. 3.3) — это во многом ключевая сфера области программной инженерии, которая находится на стыке формализации бизнес-идеи и ее воплощения в коде программного продукта. Именно поэтому основным BOK программной инженерии является именно SWEBOK — признанный стандарт деятельности в области программной инженерии.

Этот свод знаний описывает и регламентирует следующие активности:

• Инженерия требований (в большей степени системных, более формализованных и однозначных по сравнению с бизнес-требованиями).
• Область проектирования программных продуктов.
• Вопросы конструирования.
• Основные аспекты тестирования.
• Условия сопровождения.
• Управление конфигурацией программных продуктов.
• Вопросы качества программного обеспечения, не относящиеся к тестированию.
• Критерии профессионализма и уровни компетентности программных инженеров.
• Экономические затраты, связанные с разработкой продуктов.
• Основы инженерной деятельности применительно к сфере программной инженерии.

SWEBOK — самый уважаемый и авторитетный BOK, к разработке которого приступили в середине прошлого века. При этом он не является единственным — в домене системного анализа есть более высокоуровневые BOK.

Рис. 3.3.

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

SEBOK помогает определить место продукта в иерархичных социальных построениях современного мира. В нем определены:

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

и т. д.

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

IT-менеджмент

В этой области далеко не все так просто и понятно, как кажется на первый взгляд.

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

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

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

Рис. 3.4.

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

• PMBOK
  • Самое популярное руководство, описывающее суть процессов управления проектами. Это достаточно абстрактное BOK, которое не концентрируется только на сфере IT, а применимо и для других сфер. Процессы, описанные в нем, разделены на пять групп, называемых "группы процессов управления проектами". Это довольно полное, но при этом не совсем применимое для новичка руководство, с которым должен ознакомиться каждый профессионал-управленец.
• ITIL
  • Это, по сути, библиотека подходов, содержащая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области IT. Весьма конкретный свод знаний, но не очень гибкий с точки зрения поставки ценности, специализирующийся на создании структурированной процессной системы регламентации IT-деятельности.
  • Создан в Великобритании.
• PRINCE
  • Структурированный метод управления проектами. Является стандартом управления проектами в социальной сфере. Методология PRINCE2 включает в себя подходы к менеджменту, контролю и организации проектов.
  • Метод применим преимущественно в контролируемых средах.
  • Создан в Великобритании.
• P2M
  • Главное преимущество Р2М по сравнению с перечисленными конкурентами состоит в том, что в нем делается акцент на выработку инновации как подхода к управлению программами и ожиданиями заинтересованных лиц.
  • Проект в Р2М — обязательство менеджера проекта создать ценность как продукт в соответствии с миссией программы и организации в целом.
  • Создан в Японии.

Это лишь краткий перечень BOK в сфере управления IT-деятельностью. Какие-то из них подходят только для проектов, другие — только для процессов. Среди них есть более универсальные и более специфичные. Главное — выбрать тот, который лучше всего подходит для конкретных условий и обстоятельств.

Тестирование продуктов

Деятельность по тестированию программных продуктов (рис. 3.5 рис. 3.5) не должна начинаться после того, как разработчик закончил писать код, и заканчиваться в тот момент, когда тестировщик отметил, что проверил описанную функциональность. Это, пожалуй, наиболее критичная с точки зрения взаимоотношений с заказчиком область деятельности программной инженерии.

Рис. 3.5.

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

• Unit-тестирование.
• Модульное тестирование.
• Интеграционное тестирование.
• Автотестирование.
• Функциональное тестирование

и т. д.

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

Но вернемся к разновидностям BOK.

• TMBOK
  • Полный свод знаний, содержащий 7 разделов, всецело описывающих сферу тестирования. В него входят общие подходы по организации тестирования как в проектной, так и в процессной деятельности, работа над тестовыми метриками и улучшениями, риск-менеджмент, процессы автоматизации тестирования и построения общей архитектуры тестовых процессов.
• CSTE (STBOK)
  • Руководство, содержащее описание навыков, подходов, методик и стандартов, которыми должен обладать современный специалист в области тестирования. Состоит из двух частей.
• STABOK
  • Руководство, описывающее, как должно организовываться, выстраиваться и совершенствоваться автотестирование. Самое "молодое", но при этом одно из ценнейших руководств в сфере тестирования программных продуктов.

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

Архитектура программного обеспечения

Одно из самых популярных изречений об архитектуре программных продуктов (рис. 3.6 рис. 3.6) гласит, что архитектура — это самый значимый этап создания и поддержки информационных систем.

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

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

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

Рис. 3.6.

Итак, перечислим некоторые BOK, касающиеся архитектуры программного обеспечения.

• EABOK
  • Это руководство описывает, какой должна быть архитектура программного обеспечения в крупных организациях, какие виды архитектур существуют, как они связаны между собой, какие выгоды дает реализация принятых организационных архитектур. Этот документ является наиболее концептуальным и описывает самые общие части архитектур ПО в организации и их варианты.
• BIZBOK
  • Руководство, которое по сравнению с BABOK описывает, что должно происходить на следующем иерархическом уровне организации, чтобы она достигала запланированных показателей и могла устойчиво развиваться. В этом своде приведена информация о том, как выстраивать работу с стейкхолдерами, работать над стратегией, тактикой, политиками и бизнес-правилами, как внутренними, в отношении к организации, так и внешними, такими как требования законодательства. Этот BOK сконцентрирован на том, как приносить ценность за счет управляемой, измеримой разработки инновационных продуктов и услуг, отвечающих структуре и возможностям организации.
• ITABOK
  • Этот свод рассматривает пять основных практических областей, которые необходимы для построения эффективной IT-архитектуры.
  • К этим областям относят проектирование IT-решений, эффективное взаимодействие между IT и бизнесом, атрибуты качественных IT-решений, IT-окружение, необходимое для создания программных продуктов, и все это базируется на самом главном — на гибких IT-технологиях, поддерживающих развитие бизнеса.
  • В этом документе приведено более 250 навыков, которые необходимы современным архитекторам IT-решений.

Разработать успешный концепт востребованной и успешной архитектуры — это очень сложно, но это лишь 5% на пути создания продукта, который сможет удовлетворять нужды пользователей и обеспечивать ожидания руководства организаций.

Информационная безопасность

CBOK (CyBOK) — одно из самых недооцениваемых, но важных руководств, со все более возрастающим значением. Оно описывает и регламентирует то, как должна выстраиваться работа по защите информации (рис. 3.7 рис. 3.7) в современном обществе.

Рис. 3.7.

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

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

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

Вопросы для калибровки и самопроверки

А теперь, в соответствии со сложившейся структурой курса, ответим на ряд вопросов:

• Что лежит в основе успешного освоения профессии программного инженера?
  • Что первично для освоения профессии программного инженера?
  • Нужно ли родиться программным инженером, или необходимые знания и навыки можно получить и постепенно развить?
  • Как нужно развивать необходимые навыки?
• Нужно программному инженеру хорошо знать английский язык?
  • В чем преимущества знания английского языка?
  • Какая польза от занятий английским языком?
  • Сколько времени необходимо уделить освоению английского?
• Какие преимущества дает владение 10-пальцевым (слепым) методом печати?
  • Какая выгода от задействования всех 10 пальцев?
  • Насколько быстрее делает работу сотрудник, использующий при печати 10 пальцев, по сравнению с тем, кто печатает двумя или четырьмя?
• Какие из современных BOK вы знаете?
  • Все ли области деятельности, относящиеся к программной инженерии, имеют свой BOK?
  • Какой BOK произвел на вас самое большое впечатление?
  • Что из области программной инженерии осталось неформализованным в BOK?
  • Хотите внести вклад в развитие BOK вашего вида деятельности?