Этот этап планирования похож на предыдущий, а отличия состоят в следующем:
· Вы используете UML-диаграмму классов (см. Википедию, статьи “Диаграмма классов” и UML) (предыдущий этап – диаграмма в свободной форме)
· На этих диаграммах будут не объекты, а классы с упомянутыми атрибутами и методами, а также отношения классов.
Язык UML вы изучаете самостоятельно.
Q: Сколько должно быть объектных диаграмм и классовых диаграмм на каждом из этих двух этапов?
A: На каждый пользовательский сценарий вы делаете одну объектную диаграмму и одну диаграмму классов
Q: Могут ли потом быть изменения?
A: Да, но они должны быть обоснованными и их объём не должен приближаться к 100%.
Согласитесь, если вы полностью меняете внутреннюю структуру проекта, значит вы не очень эффективно реализовали этап планирования (тут нам подсказывают: подсунули халтуру, чтобы не пропустить дедлайны, но мы знаем, что среди вас таких нет) и выглядит всё это подозрительно.
Ещё раз по поводу всех изменений: мы прекрасно понимаем, что любой серьёзный проект нельзя спланировать раз и навсегда за 2 месяца, а потом реализовывать его ещё 8, не внося изменений. Однако, перед всеми нами стоят следующие задачи:
· Обеспечить чёткое планирование работы
· Обеспечить как можно более однозначно определённые критерии оценивания
· Дать вам такие инструменты работы, которые позволят хотя бы наполовину (а планирование – это как минимум половина любого дела) выполнить работу к середине срока, а не делать всё за три ночи до защиты.
Чекпоинты
Чекпоинт – это промежуточный дедлайн, к которому у вас должен быть определённый результат. Таким образом, у нас получаются следующие чекпоинты (которые имеют дедлайны):
|
|
· требования
· пользовательские сценарии
· объектные диаграммы и классовые диаграммы
· показ кода #1 – можно только код
· показ кода #2 – часть скомпилированного кода или объяснить, почему пока рано
· предоставление готового проекта на тестирование за 1 месяц до защиты
К последним двум этапам вы пишете небольшую пояснительную записку, в которой указываете, что именно вы представите к рассмотрению.
Стиль кода
Одним из критериев экспертной оценки вашего проекта будет соответствие определённым требованием к оформлению кода. Умение работать с теми или иными правилами написания – важный навык для программиста. Несмотря на то, что среди программистов, пишущих на том или ином языке, есть свои соглашения, часто IT-компании вводят свои стандарты оформления кода (например, здесь вы можете ознакомиться со стандартами Google: https://google.github.io/styleguide/).
Наши стандарты значительно проще и, в отличие от стандартов крупных корпораций, охватывают не так много аспектов: комментарии, пробелы и отступы, именование переменных.
Общее правило такое: вы можете пользоваться любым стандартом, при условии, что он не противоречит тем правилам, которым мы просим вас соответствовать.
Экспертная оценка
За этим несколько возвышенным словосочетанием стоит оценка, которую выставляет вам один из членов комиссии, обладающий статусом эксперта. Критерии оценки будут указаны ниже, однако, перед этим необходимо отметить, что эксперт делает следующее:
|
|
· после чекпоинта, на котором вы предоставляете объектные и классовые диаграммы, фиксирует функционал вашего проекта и составляет чек-лист;
· после того, как вы отправляете проект на тестирование, он проверяет наличие этого функционала в вашем продукте;
· выставляет баллы по критерию “экспертная оценка продукта”;
· пишет небольшую характеристику вашему продукту, в которой указывает общее впечатление от вашего проекта, глубину технической проработки, возможные недостатки
Критерии экспертной оценки (4 балла в сумме):
Дедлайны (ЭК-1):
· соблюдены 4-6 технических дедлайнов – 2 балла
· соблюдены 2-3 технических дедлайна – 1 балл
· соблюдены 0-1 технических дедлайнов – 0 баллов
Мы думаем, что к моменту чтения этого документа слово “дедлайн” уже прочно вошло в вашу жизнь, поэтому комментарии тут излишни, кроме одного строгого примечания: если вы не предоставляетеготовый продукт за месяц до защиты, комиссия оставляет за собой право снизить итоговую оценку на 1 балл.
Оригинальность продукта (ЭК-2):
· Проект является оригинальным или расширяет функционал имеющихся аналогов – 2 балла
· Функционал продукта копирует функционал аналогов, но по отдельным параметрам (быстродействие, удобство использования и т. п.) их превосходит – 1 балл
· Проект полностью копирует уже существующие проекты, функционально ничем не отличается от них и не предлагает никаких улучшений – 0 баллов
Стиль написания кода (ЭК-3):
· Требования к стилю кода соблюдены или имеются небольшие отклонения – 1 балл
· Имеются значительные отклонения от требований или требования к оформлению кода игнорируются – 0 баллов
|
|
Помимо экспертных критериев необходимо обратить внимания на 2 критерия из общей части, которые формально экспертными не являются, но баллы по которым будут выставляться именно экспертами (см. сводную таблицу критериев).
Продукт (критерий D)
Этот критерий можно назвать, наверное, самым главным, поскольку именно он определяет, насколько полно вы реализовали тот функционал, который вы пообещали сделать в заявке. Более подробно с этим критерием можно ознакомиться в общей таблице критериев, здесь же мы только сделаем довольно строгое примечание к нему:
Строгое примечание: в случае 0 баллов по данному критерию оценка не может быть выше “3” по пятибалльной системе; комиссия также вправе поднимать вопрос о выставлении неудовлетворительной оценки с последующей академической задолженностью по ИВР. Подобная практика позволит реализовать простую максиму “сделал другой продукт – провалил проект”. Разумеется, если функционал вашего продукта будет шире, чем вы заявили, то никаких проблем с этим не будет. Главное – не подменяйте то, что вы задумали, чем-то другим.
Ответы на экспертные вопросы на защите (см. критерий Е)
Как известно, любая ИВР заканчивается презентацией (как её делать узнает тот, кто дочитает этот документ до конца), а каждая презентация – вопросами комиссии. Все вопросы можно условно разделить на вопросы общего характера и узко-технические. Ожидается, что вы не только создадите продукт, но и будете ориентироваться в некоторых аспектах теории и практики его создания, будете владеть некоей терминологической базой (мы не будем сейчас писать список вопросов тут, будет, скорее, список тем для разговора, появится он перед защитой и будет зависеть от того, какой именно у вас проект).
Уже сейчас, однако, можно сказать, что экспертные вопросы на защите затрагивают специальные вопросы по программированию, программной структуре проекта, принципам написания кода, понятиям программирования и т. п.
Как обычно, в таких случаях – строгое примечание: в случае 0 баллов по данному критерию итоговая оценка по пятибалльной системе может быть снижена на 1 балл. Если вы не можете ответить ни на один вопрос или если ваши ответы излишне пространны, невольно закладываются всевозможные нехорошие подозрения. Надеемся, у нас не возникнет необходимости пользоваться этим правилом.
Тестирование
Процедура тестирования проходит следующим образом:
· За 1 месяц до защиты вы предоставляете полностью готовый проект (ссылку на GitHub-репозиторий).
· К этому моменту у тестировщиков на основе вашей документации (функциональные требования и т. п.) будет чеклист тех функций, которые должны быть реализованы в вашем проекте.
· Вы обязательно пишете алгоритм тестирования, в котором указываете:
1) IDE, в которой проходит тестирование;
2) необходимые SDK или иные файлы / модули / библиотеки, которые надо установить (понятно, что иногда установка IDE подразумевает установку SDK, например, IDEA и Java, но, тем не менее, мы всё равно просим указать, что именно должно быть установлено); 3) пункты меню-команды, которые нужно выбирать в IDE. Это для тех, кто, возможно, не сразу сориентируется в IDE. Поверьте, вы заинтересованы в том, чтобы тестирование вашего кода прошло без всяких багов.
· Тестировщики смотрят, реализованы ли эти функции, просматривают код, выставляют оценки по критериям ЭК-1, ЭК-2, ЭК-3.
· В случае каких-то сбоев, зависаний, непонятной работы тестировщик связывается с вами и вы обговариваете эти проблемы. В ваших интересах быть на связи регулярно, поскольку если ваш проект не запустится, а вы пропадёте, мы не сможем его оценить по критерию критерию “Продукт”.
· В случае отсутствия каких-то функций, заявленных в документации проекта, тестировщик может вам указать на эти недочёты, вы можете их исправить и вернуть ваш проект на повторное оценивание, однако, повторное оценивание никому не гарантируется и не обязательно для тестировщика. Это, скорее, жест доброй воли. Подобное положение вещей обусловлено не вредностью характеров комиссии и даже не стремлением приучить вас к дедлайнам – просто на момент тестирования все могут быть очень заняты, чтобы обращаться к каждому проекту по несколько раз.
· Если всё проходит нормально, то вы записываете демо-ролик вашего проекта.
Демо-ролик
Демо-ролик представляет собой скрин-каст на 1-2 минуты, в котором вы показываете основные принципы работы с вашим продуктом. Чтобы было совсем понятнее: если ваш проект – игра, вы играете в неё в течение 1-2 минут, если сайт – вы показываете, что можно делать на этом сайте и т. п.; плюс, демонстрируете нам всяческие ”фишки” вашего проекта. Этот ролик не должен быть техническим: не стоит нам показывать скрины из IDE или структуру кода – это рекламный, “продающий” ролик, цель которого – показать, какой крутой у вас проект. Заинтересуйте им комиссию.
Презентация
Ничего необычного здесь нет. Она состоит из:
· Введения - 1) проблемное поле, в котором работает ваш проект, 2) потенциального/реального заказчика, 3) что для вас как программиста интересно в проблеме заказчика и её решении, что показалось вам любопытным, 4) знанием и навыками в работе с какими технологиями вы не обладали до работы над проектом и чему научились в процессе (выдумывать тут не нужно: если вы все языки и фреймворки знали до начала работы, если вы в процессе работы над проектом ничего нового не узнали, это не делает ваш проект хуже, просто так и скажите, что вы были крутым уже до начала работы).
· Функционала/образа продукта – какие вы задачи поставили перед собой как подрядчик, какие функции для своего проекта вы определили и что сделано – не сделано.
· Этапов работы над проектом - (правильно понимаете, да: расскажите за 2 минуты, как вы работали целый год, ага)
· Показа демо-ролика
· Ответов на вопросы комиссии
· Ответов на вопросы эксперта
· Очень короткого отзыва эксперта о вашей работе
· Аплодисментов, цветов, автографов….
Коммуникация
Для того, чтобы мы могли просматривать и скачивать ваши проекты, вам необходимо изучать, как пользоваться Git/GitHub. Поскольку ваши проекты не коллективные, а индивидуальные, то вам не придётся изучать эту систему досконально - только самые базовые навыки по созданию, инициализации, добавлению репозиториев. Вы так же должны уметь их коммитить и пушить. Несмотря на возможную несимпатичность этих терминов, использование Git/GitHub – это необходимый навык для любого программиста.
Библиография
В заключение хотели бы отметить, что ничего нового в этом документе мы не предложили: мы воспользовались советами профессионалов, почерпнуть которые можно в источниках, указанных ниже. Некоторые из их – англоязычные. Быть программистом и не знать английский сегодня просто невозможно, так что возражений не принимаем. А вот если будут какие-то вопросы по пониманию того, что говорится и пишется – с радостью на всё ответим.
Список книг и курсов, с которыми мы рекомендуем ознакомиться:
1. Lynda.com course: Foundations of Programming: Object-Oriented Design.
2. М. Вайсфельд. Объектно-ориентированное мышление.
3. Lynda.com course: Foundations of Programming: Design Patterns.
4. Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Приемы объектно-ориентированного проектирования. Паттерны проектирования.
5. Г. Буч, И. Якобсон, Д. Рамбо. Введение в UML от создателей языка.
6. Lynda.com course: GitHub for Web Designers (James Williamson, 2014).
Список будет пополняться. To be continued, как говорится.
Дедлайны
На тот случай, если вы прочитали, всё поняли, но не совсем уяснили, что когда необходимо сдавать, мы подготовили таблицу с дедлайнами как для тех, кто будет защищаться в первую волну, так и для тех, кто защищается во вторую.
Важно: защита в первую волну не есть репетиция защиты или некий второй шанс: если вы, например, получаете оценку “3“ в первую волну, то исправить оценку, доработав проект и защитившись во вторую волну, невозможно. Пожалуйста, рассчитывайте свои силы и время.
Кроме того, невозможно отказаться от защиты в первую волну, если вы уже сделали соответствующую заявку. В этом случае отозвать заявку можно только в случае каких-нибудь сложных жизненных обстоятельств медицинского характера и т. п.
Защита в мае 2018 года:
| Событие | Дата | Как сделать? |
| 1) Заявка (hard и soft) | ноябрь, 2017 | Заполнить Гугл-форму |
| 2) Пользовательские сценарии | декабрь, 2017 | Загрузить файл на ГитХаб |
| 3) Объектные диаграммы и диаграммы UML | декабрь, 2017 | Загрузить файл на ГитХаб |
| 4) Показ когда №1 | 31 января, 2018 | ГитХаб |
| 5) Показ когда №2 | 20 марта, 2018 | ГитХаб |
| 6) Готовый продукт | 1 апреля, 2018 | ГитХаб |
Защита в ноябре 2018 года:
| Событие | Дата | Как сделать? |
| 1) Заявка (hard и soft) | ноябрь, 2017 | Заполнить Гугл-форму |
| 2) Пользовательские сценарии | январь, 2018 | Загрузить файл на ГитХабе |
| 3) Объектные диаграммы и диаграммы UML | февраль, 2018 | Загрузить файл на ГитХабе |
| 4) Показ когда №1 | март, 2018 | ГитХаб |
| 5) Показ когда №2 | май, 2018 | ГитХаб |
| 6) Готовый продукт | 15 октября | ГитХаб |
Комментарии (номер комментария соответствует номеру дедлайна):
1) Для того, чтобы отправить заявку, необходимо заполнить Гугл-форму:
https://docs.google.com/forms/d/e/1FAIpQLSeaKr_hI8-AoUnH52g09FrDBdU9PKrOrBBL2tqF7GNLSU9FEA/viewform
2) Начиная со второго дедлайна, вам необходимо иметь аккаунт и репозиторий вашего проекта на ГитХабе. Ссылку на ГитХаб впишите в Гугл-таблицу:
https://docs.google.com/spreadsheets/d/1tZLzfZxyBZiaathrgVQolkKvnWdnu-YDu-W5stesZ6w/edit?usp=sharing
3) пользовательские сценарии должны быть в корне репозитория; файл должен называться ivanov_user_scripts,где первая часть имени файла – ваша фамилия
4) объектные диаграммы и UML-диаграммы в должны быть в корне репозитория; файл должен называться ivanov_diagrams,где первая часть имени файла – ваша фамилия
Авторы документа:
Купцов А. А., Сёмина С. Е., кафедра исследовательской и проектной деятельности
Контакты: akuptsov.hse@gmail.com https://vk.com/alekscooper
[1] Национальный стандарт Российской Федерации ГОСТ Р ИСО 21500-2014 – Руководство по проектному менеджменту. М.: Стандартинформ, 2015. 52 c.
URL: https://protect.gost.ru/document.aspx?control=7&id=198457
[2] Что? Ссылка на Википедию?? Как возможно??? Отвечаем: во-первых, наш документ - это не исследование, это гайд для дальнейшей работы, во-вторых, Википедия – не проблема сама по себе, проблема – если вы, не владея терминологией и пониманием ООП, ограничитесь только Википедией. Мы подскажем в конце документа, что почитать по ООП.