Primary tabs
Forums:
Вопросы к 1-й рубежной аттестации =
1. Что такое технология программирования? Методы и средства разработки программных продуктов?
2. Понятие качества программных продуктов. Критерии качества.
3. Определение качества ПО в стандарте ISO 9126. Аспекты качества, их взаимное влияние.
4. Многоуровневая модель качества ПО в стандарте ISO 9126.
5. Стратегии и модели процесса разработки программных средств? Модель жизненного цикла программных средств. Фазы жизненного цикла.
6. Этапы классического жизненного цикла, их содержание.
7. Цели стандартизации в сфере производства программных средств. Преимущества стандартизации для заказчика и исполнителя. Международные и национальные стандарты. Организации, занимающиеся разработкой стандартов.
8. Стандарт ISO/IEC 12207-95: основные определения – система, модель жизненного цикла, квалификационные требования.
9. Стандарт ISO/IEC 12207-95: основные процессы, их содержание.
10. Стандарт ISO/IEC 12207-95: работы и задачи процесса разработки.
11. Стандарт ISO/IEC 15504 (SPICE): оценка возможностей разработчика. Связь этого стандарта с моделью зрелости предприятия SEI CMM.
12. Стандарт ISO 9126: оценочные характеристики качества программного продукта.
13. Каскадная модель процесса разработки, ее характеристика. Инкрементная модель процесса разработки, ее характеристика.
14. RAD-модель процесса разработки, ее характеристика. Этапы и рабочие потоки процесса разработки.
15. Спиральная модель процесса разработки, ее характеристика.
16. Прогностические и адаптивные процессы разработки программных средств. Методология экстремального программирования.
17. Прогностические и адаптивные процессы разработки программных средств. Scrum-модель процесса разработки.
18. Руководство процессом разработки программного средства: цели и задачи. Планирование процесса разработки, типовая структура распределения работ.
19. Оценка хода выполнения программного проекта, меры и метрики. Размерно- и функционально-ориентированные метрики.
20. Анализ предметной области: цели и задачи. Модели предметной области. Формальные определения. Классификация моделей.
21. Методология IDEF0, синтаксис IDEF0-моделей.
22. Диаграммы потоков данных (DFD-диаграммы), их использование при моделировании предметной области.
23. Диаграммы потоков работ (IDEF3-диаграммы), их использование при моделировании предметной области.
24. Цели и задачи этапа проектирования. Стадии проектирования, их краткая характеристика.
25. Задачи, решаемые на стадии эскизного проектирования.
26. Понятие архитектуры ПС. Проблема выбора архитектуры. Влияние архитектуры на качественные характеристики ПС.
27. Модели системного структурирования, их характеристики.
28. Понятие модуля и модульного программирования. Преимущества модульного подхода к разработке ПО.
29. Задачи, решаемые на стадии детального проектирования.
30. Цели и задачи проектирования пользовательского интерфейса.
31. Понятие шаблона. Классификация шаблонов. Стандарт описания шаблонов
32. Шаблоны анализа (analysis patterns), их классификация.
33. Архитектурные шаблоны (architectural patterns), их классификация.
34. Шаблоны проектирования (design patterns), их примеры.
=========================================================================
Список вопросов ко 2-й рубежной аттестации
по курсу «Технология программирования»
1. Задачи этапа объектно-ориентированного анализа предметной области. Методика определения границ системы и ключевых абстракций. Пример проведения анализа.
2. Функциональные требования к системе. Способ их представления в виде UML-диаграммы. Пример диаграммы с использованием отношений «расширяет» и «включает».
3. Понятие прецедента и сценария. Пример прецедента, основного и дополнительного сценариев.
4. Нефункциональные требования к системе, их виды. Примеры нефункциональных требований.
5. Концептуальная модель системы: концептуальные классы, системные события и системные операции. Способ их представления в виде UML-диаграмм. Пример концептуального описания прецедента.
6. Диаграммы взаимодействия как элементы концептуальной модели. Синтаксис диаграмм взаимодействия. Примеры диаграмм взаимодействия.
7. Задачи этапа объектно-ориентированного проектирования. Понятие модели проектирования, ее отличия от концептуальной модели.
8. Обязанности программных классов, виды обязанностей. Визуализация распределения обязанностей посредством UML-диаграмм. Примеры диаграмм.
9. Шаблоны проектирования, их классификация. Правила описания шаблонов, примеры шаблонов с их описаниями.
10. Шаблоны распределения обязанностей, их назначение. Примеры применения.
11. Идентификация методов программных классов. Диаграммы классов, способы отображения отношений ассоциации и зависимости. Пример диаграммы классов.
12. Структурные шаблоны, их назначение. Примеры структурных шаблонов с их описаниями.
13. Метрические характеристики объектно-ориентированных систем. Метрики Чидамбера и Кемерера.
14. Тестирование программного средства. Стадии тестирования и их характеристика.
15. Основные принципы тестирования.
16. Тесты и тестовые наборы. Понятие тестового покрытия. Отладочное тестирование. Соотношение структурного и функционального подходов.
17. Структурный подход к формированию тестовых наборов. Пример реализации структурного подхода.
18. Функциональный подход к формированию тестовых наборов. Пример реализации функционального подхода.
19. Интеграционное тестирование. Виды интеграционного тестирования. Критерии полноты тестовых наборов.
20. Регрессионное тестирование. Критерии завершения отладочного тестирования.
21. Восходящая стратегия интеграционного тестирования, механизм ее реализации.
22. Нисходящая стратегия интеграционного тестирования, механизм ее реализации.
23. Системное тестирование. Виды системного тестирования. Критерии полноты тестовых наборов.
24. Особенности объектно-ориентированного тестирования. Расширение области применения тестирования. Критерии тестирования моделей.
25. Особенности методики модульного тестирования объектно-ориентированных систем. Тестирование классов.
26. Особенности методики интеграционного тестирования объектно-ориентированных систем. Тестирование кластеров и потоковое тестирование.
27. Понятие автоматизированного тестирования. Автотесты. Достоинства и недостатки автоматизированного тестирования.
28. Типы автоматизированного тестирования, их цели. Средства автоматизированного тестирования.
29. Утилита модульного тестирования NUnit. Средства описания тестов.
30. Утверждения, параметры утверждений.
31. Группы утверждений, классическая и закрытая модель утверждений.
32. Директивы, категории директив.
Список вопросов к 3-й рубежной аттестации
по курсу «Технология программирования»
1. Понятие версии программного продукта и системы контроля версий.
2. Две модели версионирования, их сравнение.
3. Система конкурирующих версий CVS, ее достоинства и недостатки.
4. Система Subversion, ее архитектура; достоинства и недостатки системы.
5. Хранилище, его структура, правки. Команды SVN для работы с хранилищем.
6. Понятия рабочей копии и служебного каталога. Команды SVN для работы с рабочими копиями.
7. Сценарий объединения правок. Конфликты и способы их разрешения.
8. Понятие сборки, манифест сборки.
9. Сборка приложения, системы автоматизации сборки.
10. Утилита NAnt, файл сборки и его структура.
11. Цели, зависимость целей, описание целей.
12. Команды NAnt, примеры команд.
13. Документирование процесса разработки. Типы документов управления.
14. Документирование программного продукта. Документация сопровождения, ее назначение и состав.
15. Документирование программного продукта. Пользовательская документация, ее назначение и состав.
Статья будет полезна руководителям подразделений/проектов, у кого ещё не сформирован свой фиксированный перечень вопросов, по которому они определяют, подходит им кандидат или нет.
Также будет полезна программистам, которые задумываются о карьерном росте, и ещё не сформировали себе окончательный карьерный план, возможно, в него имеет смысл внести коррективы.
Попытался систематизировать собственный опыт и некоторые знания в области HR, составив некоторый портрет "идеального программиста 1С". После того, как такой "портрет" получилось построить, выбрал все знания/умения/навыки, которыми такой "идеальный" кандидат должен обладать, выбрал 10 наиболее важных (по моему опыту) и сформулировал вопросы, которыми данные качества/знания/навыки можно проверить. Всё это мы неоднократно проделываем на собеседовании, вот только времени обычно на это минуты 2-3, потому как не привыкли же мы заранее продумывать вопросы, которые зададим.
Расшифровка результатов ответов приведена в конце статьи
Вопрос 1. Есть ли у Вас сертификаты 1С? Какие?
В России мы привыкли пренебрежительно относиться ко "всякого рода бумажкам". Это общий подход. Жизнь научила нас им не доверять. Привыкли мы к "купленным правам", "купленным дипломам" и т.п. Тем не менее, таким замечательным инструментом первичной оценки знаний нужно пользоваться. 1С достаточно трепетно относится к выдаче своих сертификатов (что касается "Специалист" и выше). "Покупать" сертификаты вряд ли кто будет – не такая это большая ценность, чтобы пытаться, да и не просто это, я думаю. Круг лиц весьма ограничен.
А о чём говорит сертификат "1С Специалист":
– Есть хоть какая-то школа. При сдачи экзаменов 1С смотрят не просто как человек умеет ездить (программировать), а как человек умеет ездить по правилам (программировать по методикам)
– Как минимум – человек программировать в 1С умеет, может и не большой профи, но умеет, поэтому кучу всевозможных проверок одним вопросом мы отбрасываем
Лучше всего если у кандидата несколько сертификатов – по платформе и по прикладному решению с которым ему предстоит работать.
Но очень внимательно отнеситесь если у кандидата много сертификатов, либо среди них есть сертификаты вида "Руководитель проекта, ведущий консультант, Эксперт по техн. вопросам". Если эти люди ищут работу обычным программистом – на то должны быть другие причины, кроме того уровень желаемого дохода может оказаться несоразмерным вашему бюджету.
Вопрос 2. Вы знакомы с документом "Система стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8"?
Сам документ находится на любом диске ИТС или http://its.1c.ru/db/v8std#browse:13:-1
Если нужно проверить знание самого документа, можно спросить из каких частей в общем случае состоит программный модуль системы ответ должен быть примерно таким:
- заголовок модуля
- раздел описания переменных
- процедуры и функции модуля
- обработчики событий элементов формы
- обработчики событий
- раздел инициализации
Лично мое мнение этот документ должен знать каждый программист. Этим отличается квалифицированный программист от "программера". Именно из за того что следовать методикам часто не принято, а преобладает "я сам лучше знаю как надо" получаются многие "кривые" прикладные решения. А если отойти от 1С это основная "болезнь" русских программистов, на эту тему уже множество шуточных статей вроде этой: http://blog.sjinks.pro/humour/76-programmers-russian-indian-chinese-canadian/
Вопрос 3. Вам нужно разработать прикладное решение "с нуля" с чего вы начнете?
Жизненный вопрос, правда? "Правильный" программист вспомнит теорию ещё с университетской скамьи (анализ требований, составление спецификации).
Ещё более правильный вспомнит что перед сбором и анализом требований хорошо бы провести цельное исследование – познакомиться с бизнес-процессами компании. Ну и совсем правильно будет ещё взять правильную основу для разработки – 1С нам подарила замечательную "библиотеку стандартных подсистем": http://its.1c.ru/db/bspdoc#browse:13:-1
Вопрос 4. Насколько хорошо вы знаете функциональность прикладного решения ". "? Перечислите основные процедуры проведения Документа в решении ". ".
"Доверяй но проверяй". Прикладное решение естественно должно использоваться (планироваться к использованию) в вашей организации и заявлено у программиста в резюме как знакомое. Собственно если человек достаточно хорошо знает "внутренности" того или иного прикладного решения, В модули проведения документа он вмешивался не один раз. Изменения, которые не влияют на проведение, часто можно считать "косметическими". А уж если приходилось добавлять новые документы в рамках функциональности прикладного решения, и добавлять их "правильно", то эти процедуры надолго отложатся в памяти. Проверить конечно это стало достаточно трудно, т.к. в решениях на 8.2 логика проведения поменялась, и следовательно процедуры поменялись тоже.
Для УТ 11 на момент написания статьи они такие:
ИнициализироватьДополнительныеСвойстваДляПроведения(Ссылка, ДополнительныеСвойства, РежимПроведения);
ИнициализироватьДанныеДокумента(Ссылка, ДополнительныеСвойства);
ПроведениеСервер.ПодготовитьНаборыЗаписейКРегистрацииДвижений(ЭтотОбъект);
. ОтразитьДвижение. (ДополнительныеСвойства, Движения, Отказ);
СформироватьСписокРегистровДляКонтроля();
ЗаписатьНаборыЗаписей(ЭтотОбъект);
ВыполнитьКонтрольРезультатовПроведения(ЭтотОбъект, Отказ);
Вообще программист 1С должен хорошо ориентироваться во всех типовых конфигурациях, потому что основная работа квалифицированного программиста не написать код, а грамотно спереть код оттуда где подобная задача уже решена.
Вопрос 5. Перечислите все статьи баланса, которые вы знаете.
Простой тест на превичное знание бух. и упр. учета. Собственно должно получиться что-то похожее на http://blanker.ru/files/forma-1-balans-2003-q1.doc В зависимости от вида формы и названия статей можно так определить с каким балансом больше имел дело человек с бухгалтерским или управленческим. По большому счету, незнание структуры баланса не говорит о том что перед нами плохой программист, но говорит о том что перед нами "только программист".
Вопрос 6. Вам знакомо понятие "Валюта Баланса"?
Вопрос убивает 2-х зайцев одним выстрелом: проверяет возможные необдуманные действия и знание бухгалтерского учета.
Казалось бы самый простой ответ "валюта в которой формируется баланс". но в этом и есть вся загвоздка – это не так. Это первичное понятие БУ. Собственно не знание его означает уже не знание БУ как такового, а ответ "валюта в которой" лишь попытки догадки без знаний, что характеризует кандидата не с лучшей стороны.
Вопрос 7. Технический back ground. Вы знаете MS SQL? Знаете MS AD? Основные сетевые протоколы?
Проверить знания MS SQL можно к примеру вопросом "Для чего используется статистика MS SQL" или "что такое план запроса".
Собственно статистика нужна для построения плавильных планов запросов, а планы запросов:
MS AD – практически стало стандартом организации ИТ инфраструктуры.
Знание сетевых протоколов можно к примеру спросить чем отличается TCP от UDP http://ru.wikipedia.org/wiki/TCP и http://ru.wikipedia.org/wiki/UDP Собственно отличается TCP предварительной установкой соединения.
Хороший технический Background необходим для квалифицированного программиста, т.к. часто приходится решать смежные задачи: оптимизация базы потребует зания MS SQL, настройка и развертывание сервера потребует первичных знаний AD. Организация интеграции с другими системами потребует знания сетевых протоколов и т.д. Очень часто "бедой" "программистов 1С" является то, что кроме 1С собственно ничего и не видели. Особенно если образование не техническое, или "не информационное". Это сужает круг задач, которые они могут решать.
Вопрос 8. Вы знаете другие языки программирования (C++, C#)?
Получив утвердительный ответ тоже хорошо бы проверить, спросив что такое наследование (http://ru.wikipedia.org/wiki/%D0%9D%D0%B0%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)) и Полиморфизм (http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BB%D0%B8%D0%BC%D0%BE%D1%80%D1%84%D0%B8%D0%B7%D0%BC_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)). т.к. оба этих языка являются объектно-ориентированными, наследование и полиморфизм заложены в их основу.
Знание других языков программирования говорит о хорошей подготовке программиста, кроме того, о понимании "основ" построения информационной системы. Кроме того, некоторые технологии (COM OLE .NET WS) являются общими для различных языков программирования, поэтому их использование для интеграционных проектов окажется более простым
Вопрос 9. Бухгалтер просит вас перенумеровать счета фактуры по организации ООО ". " за текущий месяц. Посмотрев ситуацию вы находите там всего 10 счетов фактур. Что бы вы сделали?
Самая типичная ситуация на примере которой выясняется личностное поведение программиста. Однозначно правильного ответа на данный вопрос нет. Зато есть однозначно неправильный – "перенумерую руками". Это именно то поведение, которое часто встречается даже у квалифицированных программистов, но резко снижает их полезность для организации. Выполнять какую-либо операторскую работу программист не должен – это не рентабельно для компании, т.е. разница в з/п обычно составляет 2-3 и более порядков.
Идеальным вариантом будет использование ключевой фразы: "при отсутствии текущих задач" или "небольшой текущей загрузке" напишу илилучше скачаю механизм перенумерации объектов, и научу бухгалтера им пользоваться. Либо "при высокой текущей загрузке" позвоню и вежливо предложу перенумеровать СФ самостоятельно, в случае необходимости объясню как это сделать.
Но собственно в данном случае всё зависит от того, какого человека вы ищите. Если проектника (задачи внедрения), то конечно иделальным поведением будет "вежливо попросить" бухгалтера не приставать с такими вопросами, если же на поддержку, то вариант с "вежливо попросить" просто отпадает.
Вопрос 10. Вам знакома библиотека ITIL? А технология PMI?
Если вы ищите только программиста, то на эти вопросы лучше если будет отрицательный ответ. ITIL – библиотека Best practice процессного менеджмента для управления процессами ИТ. PMI – технология управления проектами. Собственно 2 самых популярных инструмента ИТ руководителей на момент написания данной статьи. Если кандидат знаком с ITIL следовательно он наметил для себя карьеру ИТ директора в будущем. Если PMI – следовательно стремится стать менеджером проектов. Если же человек достаточно хорошо знаком или с одним или с другим то нужно заранее планировать либо карьерный рост кандидата, либо его уход из компании.
Расшифровка результатов
Естественно все результаты рассмотреть не получится – много возможных сочетаний. Могу только сказать что вопросы расположены в порядке убывания их значимости. В принципе положительно ответивший на первые 3-4 вопроса кандидат – уже очень хороший вариант для приёма на работу/в проектную команду. В таблице ниже попытался рассмотреть ещё несколько "типичных" случаев программистов, и по каким ответам их проще распознать. Ответы не обязательно полностью должны совпасть с тем что указано. На указанные вопросы должны быть положительные ответы – точно. Может быть ещё 1 или 2 положительных ответа. Особое внимание стоит обратить только на вопросы 7 и 8. Человек ответивший положительно только на них как правило не тот кто вам нужен.
Ответы
Комментарий
Денег платить придётся не мало. Кандидат конечно этого стоит, но столько ли у вас задач, чтобы использовать потенциал? Посадить такого программиста на суппорт будет явно не рентабельно
Вы готовы заняться обучением?
Типичный случай бухгалтера-программиста. Не очень плохой вариант. Нужно дополнительно пообщаться на предмет технического мышления. Если хоть немного присутствует для суппорт-а бухгалтерии и финансов такой программист очень неплохо подойдёт. Для реальной разработки сложного и нового функционала – скорее нет
Очень плохой случай. Вы имеет дело с типичным технарем. Как правило, эти люди очень самолюбивы, 1С считают «убогим продуктом, с которым им приходится работать». Управлять ими трудно, добиться чего-либо полезного ещё труднее. Все задачи решаются «творчески». Часто поступают «интересные» предложения вроде «перейти на Linux», написать систему самому на C++ и т.п. Без «плюсов» в 1, 2 и 3 таких людей лучше не брать.
Собственно перед вами скорее человек который претендует на руководящую позицию чем разработчик.
Перед вами Администартор-программист. Очень часто в мелких компаниях одному человеку приходится сочетать эти качества. Человек привык к суппорту наверно даже идеален для такового, но для использования в более серьёзных проектах скорее всего потребуется дополнительное обучение.
Дисклеймер: если после прочтения этого текста вы захотите внедрить KPI для программистов — сходите прочитать еще и это.
Недавно я писал о том, как были придуманы карты компетенции и как мы применяем их на стажерах. Сами карты были придуманы в помощь для аттестации программистов. Сама аттестация — дело сложное, муторное, и часто — неблагодарное.
Итак, какие цели преследует аттестация.
Решение
Для того, чтобы вся схема работала, мы разработали и внедрили такую модель аттестации:
Шаг 1. Заполнение карты компетенции. Перед аттестацией ее заполняет каждый разработчик. Если будете внедрять, обязательное требование — сделать заполнение карты компетенции регулярным.
Шаг 2. Сама аттестация. Всегда происходит один на один с разработчиком.
Мы беседуем и сравниваем карты компетенции: текущую и предыдущие. Так можно отследить прогресс и смену ориентиров конкретного человека.
Дальше — анализируются потребности (технологические «хотелки») разработчика. Для того, чтобы помочь прокачать какую-то технологию, студия может предложить три варианта:
- Во-первых и самых главных — попробовать ставить человека на реальный боевой проект с подобной технологией, когда (и если) так выпадут звезды.
- Изучить факультативно. Тут два варианта. Предпочтительный — устроить хакатон, так получается больше практических знаний (так мы сделали Whoision, на минутку). Альтернативный — провести холивар по теме, а разработчика назначить докладчиком.
- Изучить самостоятельно. Тут все в руках самого программиста, помочь можем рекомендациями, что почитать, с кем в студии поговорить и можем поверить знания.
В связи с последним в карту компетенции сейчас добавили список литературы: книг, без понимания которых «крутым» себя считать вряд ли можно. Ну или, по крайней мере, они сильно ускоряют процесс наращения крутизны.
Шаг 3. Кодревью. Мной отсматривается код программиста — реальные проекты, над которыми он работал в последние полгода.
Совсем не факт, что кодревью выявит какие-то глубинные ошибки. Для этого нужно слишком много времени. Оно направлено, скорее, на формирование общего представления об уровне разработчика. Такое знание пригодится при формировании команд (опытные/новички) и при распределении задач внутри команды.
Linus Torvalds
Шаг 4. Подведение итогов. В результате разработчик получает три ценных директивы: что почитать, что подтянуть, что попробовать из нового.
Например, в ходе одной из аттестаций мы с разработчиком решили, что ему нужно прокачаться в Линуксе. В итоге снесли на его рабочей машине винду.
Находка: в ходе аттестации мы также применяем вариацию известного «метода 360 градусов». Мы разговариваем с человеком, просим рассказать про конкретных людей, с которыми он работал, их сильных и слабых сторонах. Так как в Скраме все проекты делаются в небольших командах, то такой «инсайдер» может дать наиболее ценные рекомендации.
Чего нет в нашей системе аттестации — так это балльной системы и прочей формалистики.
Итого. Сложности внедрения
Если вы захотите внедрить у себя что-то подобное, то будьте готовы как минимум к трем трудностям:
- Это отнимает очень много времени.
- Не каждому руководителю хочется этим заниматься: говорить, выяснять и уточнять, чтобы не было недопонимания и недомолвок.
- Советы, которые вы даете по итогам аттестации — это и просто рекомендации, и императивные указания с занесением в персональный план и контролем выполнения.
Когда-то давно я писал про выведение KPI для разных специалистов, текст всё еще очень актуальный, можете присоединяться к дискуссии, если что. А если лениво читать, то вывод там был вполне однозначный: KPI для разработчиков — не работает. Но какой-то измеритель все равно быть должен — в нашем случае это аттестации.
Цель аттестации: не судить разработчика, а помочь ему расти. По результатам пары успешных аттестаций у разработчика может случиться апгрейд зарплаты. По-хорошему, аттестацию нужно проводить регулярно (пару раз в год).
Мысли и замечания предлагаю смело высказывать ниже, с удовольствием послушаю и отвечу!
