Протухшие ссылки в курсе ТРПО

[WoWaster]

Протухла ссылка на статью о Write-only ЯП:

courses/software-technology/01-software-engineering/01-software-engineering-text.tex

Line 22 in fc6698a

При перемещении по стрелке вниз программа превращается в программный продукт. Это программа, которую любой человек может запускать, тестировать, исправлять и развивать. Она может использоваться в различных операционных средах и со многими наборами данных. Чтобы стать общеупотребительным программным продуктом, программа должна быть написана в обобщенном стиле. В частности, диапазон и вид входных данных должны быть настолько обобщенными, насколько это допустимо. Затем программу нужно тщательно протестировать, чтобы быть уверенным в ее надежности. Для этого нужно подготовить достаточное количество контрольных примеров для проверки диапазона допустимых значений входных данных и определения его границ, обработать эти примеры и зафиксировать результаты. Приложению нужен хороший пользовательский интерфейс, который нужно будет ещё разработать. Наконец, развитие программы в программный продукт требует создания подробной документации, с помощью которой каждый мог бы использовать ее, делать исправления и расширять. Ну и сама программа должна быть написана так, чтобы её потенциально можно было адекватно расширять и сопровождать\footnote{См. \url{https://en.wikipedia.org/wiki/Write-only_language}.}. По разным эмпирическим оценкам программный продукт стоит в 3-10 раз дороже, чем просто отлаженная программа с такой же функциональностью.

Может быть пойдёт что-то типа: https://wiki.c2.com/?WriteOnlyLanguage
Или взять из архива: https://web.archive.org/web/20231211024014/https://en.wikipedia.org/wiki/Write-only_language
И ещё забавность: https://web.archive.org/web/20160305001039/http://catpad.net/michael/apl/

[WoWaster]

Еще протухла ссылка на новый профстандарт:

courses/software-technology/01-software-engineering/01-software-engineering-text.tex

Line 86 in fc6698a

Имеющиеся промышленные стандарты для профессии <<Программист>> (более старый\footnote{Стандарт АПКИТ 2007 года, \url{http://www.apkit.ru/files/programer.doc} (дата обращения: 09.02.2023).} и более новый\footnote{Профстандарт Министерства труда и социальной защиты 06.001, <<Программист>>, 2022 года \url{https://profstandart.rosmintrud.ru/obshchiy-informatsionnyy-blok/natsionalnyy-reestr-professionalnykh-standartov/reestr-professionalnykh-standartov/index.php?ELEMENT_ID=115615} (дата обращения: 09.02.2023).}) подтверждают эти мысли:

Кажется сейчас он живет тут: https://profstandart.rosmintrud.ru/obshchiy-informatsionnyy-blok/natsionalnyy-reestr-professionalnykh-standartov/reestr-professionalnykh-standartov/index.php?ELEMENT_ID=120722

[WoWaster]

Ссылка на статью Ройса:

courses/software-technology/02-lifecycle/02-lifecycle-text.tex

Line 32 in fc6698a

Наиболее широко известной и применяемой долгое время оставалась так называемая каскадная или водопадная (waterfall) модель жизненного цикла, которая, как считается, впервые четко сформулирована в 1970 году Винстоном Ройсом в работе <<Managing the Development of Large Software Systems>>\footnote{\url{http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf} (дата обращения: 25.02.2022).} и впоследствии запечатлена в стандартах министерства обороны США в семидесятых-восьмидесятых годах XX века. Эта модель предполагает последовательное выполнение различных видов деятельности, начиная с выработки требований и заканчивая сопровождением, с четким определением границ между этапами, на которых набор документов, созданный на предыдущей стадии, передается в качестве входных данных для следующей. Таким образом, каждый вид деятельности выполняется на какой-то одной фазе жизненного цикла. <<Классическая>> каскадная модель предполагает только движение вперед по этой схеме: все необходимое для проведения очередной деятельности должно быть подготовлено в ходе предшествующих работ. Отмечалось, что возвраты могут катастрофически увеличить стоимость проекта и сроки его выполнения. Например, если при тестировании обнаруживаются ошибки проектирования или анализа, то их исправление часто приводит к полной переделке системы. Этой моделью допускались возвраты только на предыдущий шаг: например, от тестирования к кодированию, от кодирования к проектированию и т.д.

Почему-то под более поздней датой, но на ACM в открытом доступе: https://dl.acm.org/doi/10.5555/41765.41801

[WoWaster]

Ссылка на статью Боэма:

courses/software-technology/02-lifecycle/02-lifecycle-text.tex

Line 60 in fc6698a

Развитием идеи итераций является спиральная модель жизненного цикла ПО, предложенная Боэмом в 1988 году\footnote{\url{http://csse.usc.edu/TECHRPTS/1988/usccse88-500/usccse88-500.pdf} (дата обращения: 25.02.2023).}. Она предлагает каждую итерацию начинать с выделения целей и планирования очередной итерации, определения основных альтернатив и ограничений при ее выполнении, их оценки, а также оценки возникающих рисков и определения способов избавления от них, а заканчивать итерацию оценкой результатов проведенных в ее рамках работ. Основным ее новым элементом является общая структура действий на каждой итерации --- планирование, определение задач, ограничений и вариантов решений, оценка предложенных решений и рисков, выполнение основных работ итерации и оценка их результатов.

Требует университетский доступ, но навряд ли быстро протухнет: https://ieeexplore.ieee.org/document/59

[WoWaster]

courses/software-technology/02-lifecycle/02-lifecycle-text.tex

Line 88 in fc6698a

Ещё одним примером спиральной модели является модель Эрика Рисса\footnote{\url{https://www.ozon.ru/context/detail/id/18322266/} (дата обращения: 25.02.2023).}. Модель итерационная, состоящая из трех этапов. Каждый этап дает на выходе артефакт, используемый в следующем этапе.

Просто более стабильная ссылка: https://books.google.ru/books/about/%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81_%D1%81_%D0%BD%D1%83%D0%BB%D1%8F.html?id=yqiBAwAAQBAJ&redir_esc=y

[WoWaster]

Ссылка рабочая, но не кликабельная:

courses/software-technology/03-scrum/03-scrum-text.tex

Line 14 in fc6698a

В соответствии с Руководством по Скраму\footnote{https://scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Russian.pdf (дата обращения: 04.03.2023).}, Скрам --- фреймворк, предоставляющий спектр возможностей для продуктивной и творческой разработки продуктов с максимально возможной ценностью и решения нетривиальных задач в процессе работы.

[WoWaster]

Сноска на вики --- не url:

courses/software-technology/03-scrum/03-scrum-text.tex

Line 90 in fc6698a

Как оценить задачу так, чтобы все приняли согласованное решение? Есть много разных практик оценивания. Одна из них --- planning poker\footnote{см., например, \url{https://firepoker.io/} (дата обращения: 04.03.2023).}. Выглядит примерно так: заводятся специальные карточки, на которых написаны числа. Например: 1, 2, 3, 5, 8... Каждому участнику обсуждения выдаётся по одной колоде карт (в этом процессе оценивания участвуют только разработчики, Product owner наблюдает, Scrum master модерирует). Участники выбирают по одной карте и кладут их рубашкой вверх, показывая таким образом, что выбор сделан. Затем все эти карточки переворачиваются и сравниваются. (Таким образом, покер планирования минимизирует эффект привязки\footnote{https://ru.wikipedia.org/wiki/Эффект\_привязки (дата обращения: 04.03.2023).} путем опроса каждого из участников команды таким образом, что никто не знает чужого решения до одновременного оглашения выбора каждого из участников.) Участникам с различающимися оценками дается возможность высказаться и обосновать свой выбор. Таким образом происходит обмен информацией о задаче. После обсуждения проводится повторное голосование, и так до тех пор, пока не будет достигнут консенсус. Любая задача в ходе итерации может достаться любому разработчику, поэтому крайне важно, чтобы каждый чувствовал в себе уверенность выполнить задачу за то количество поинтов, за которое он голосует.

[WoWaster]

Первая ссылка:

courses/software-technology/05-user-interfaces/05-user-interfaces-text.tex

Line 132 in fc6698a

Про то, как организовать процесс построения персонажей, можно прочитать тут: \url{https://uxexperience.net/useful/artefakty-persona} (дата обращения: 12.03.2023). А про то, сколько времени может занимать эта работа --- тут: \url{https://www.nngroup.com/articles/persona-budgets/} (дата обращения: 12.03.2023).

Только так видимо: https://web.archive.org/web/20230331163228/https://uxexperience.net/useful/artefakty-persona

[WoWaster]

courses/software-technology/05-user-interfaces/05-user-interfaces-text.tex

Line 160 in fc6698a

Разумеется, никто не говорит, что надо забить на пользователей и делать всё, как нам захочется. Данный подход всё так же анализирует поведение пользователей, однако тут скорее идёт анализ того, что пользователь делает с инструментом/продуктом, и насколько это приближает его к решению изначальной задачи\footnote{Про всё это поподробнее можно почитать по ссылкам \url{http://jnd.org/dn.mss/human-centered_design_considered_harmful.html} (дата обращения: 12.03.2023) и \url{https://medium.com/@collabject/stop-designing-for-users-9c5e582b3ec8} (дата обращения: 12.03.2023).}.

Первая ссылка теперь здесь: https://jnd.org/human-centered-design-considered-harmful/
На Medium теперь только с VPN

[WoWaster]

Опечатка: > не нужна

courses/software-technology/05-user-interfaces/05-user-interfaces-text.tex

Line 384 in fc6698a

\item A/B-тестирование\footnote{\url{http://texterra.ru/blog/kak-provodit-a-b-testiro>vanie.html} (дата обращения: 12.03.2023).}

[WoWaster]

Нужен VPN

courses/software-technology/05-user-interfaces/05-user-interfaces-text.tex

Line 385 in fc6698a

\item Эвристический анализ интерфейса\footnote{\url{https://turumburum.ua/blog/evristicheskaya-otsenka-yuzabiliti-sayta} (дата обращения: 12.03.2023).}

[WoWaster]

Jenkins и TeamCity не кликабельны:

courses/software-technology/13-ci-cd/13-ci-cd-text.tex

Line 204 in fc6698a

Заметьте, что для того, чтобы внедрить CI в ваш проект, вам не нужно каких-то особых инструментов. В статье \url{http://www.jamesshore.com/v2/blog/2006/continuous-integration-on-a-dollar-a-day} (дата обращения: 21.05.2023), например, приводится пример, как внедрить CI в проект при помощи одного компьютера, резинового цыплёнка и звонка-колокольчика. И всё же, в настоящее время есть целая куча удобных тулов для CI, например, опенсорсный Jenkins\footnote{Домашняя страница Jenkins, URL: https://www.jenkins.io/ (дата обращения: 21.05.2023).} или более платный TeamCity\footnote{Домашняя страница TeamCity, URL: https://www.jetbrains.com/teamcity/ (дата обращения: 21.05.2023).}. Ещё куча тулов представлена в сравнении здесь: \url{https://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software} (дата обращения: 21.05.2023).