%% %% Copyright 2007-2019 Elsevier Ltd %% %% This file is part of the 'Elsarticle Bundle'. %% --------------------------------------------- %% %% It may be distributed under the conditions of the LaTeX Project Public %% License, either version 1.2 of this license or (at your option) any %% later version. The latest version of this license is in %% http://www.latex-project.org/lppl.txt %% and version 1.2 or later is part of all distributions of LaTeX %% version 1999/12/01 or later. %% %% The list of all files belonging to the 'Elsarticle Bundle' is %% given in the file `manifest.txt'. %% %% Template article for Elsevier's document class `elsarticle' %% with harvard style bibliographic references \documentclass[preprint,12pt,authoryear,dvipdfmx,review]{elsarticle} %% Use the option review to obtain double line spacing %% \documentclass[authoryear,preprint,review,12pt]{elsarticle} %% Use the options 1p,twocolumn; 3p; 3p,twocolumn; 5p; or 5p,twocolumn %% for a journal layout: %% \documentclass[final,1p,times,authoryear]{elsarticle} %% \documentclass[final,1p,times,twocolumn,authoryear]{elsarticle} %% \documentclass[final,3p,times,authoryear]{elsarticle} %% \documentclass[final,3p,times,twocolumn,authoryear]{elsarticle} %% \documentclass[final,5p,times,authoryear]{elsarticle} %% \documentclass[final,5p,times,twocolumn,authoryear]{elsarticle} %% For including figures, graphicx.sty has been loaded in %% elsarticle.cls. If you prefer to use the old commands %% please give \usepackage{epsfig} %% The amssymb package provides various useful mathematical symbols \usepackage{amssymb} \usepackage{url} \usepackage{booktabs} \usepackage[strings]{underscore} %% The amsthm package provides extended theorem environments %% \usepackage{amsthm} %% The lineno packages adds line numbers. Start line numbering with %% \begin{linenumbers}, end it with \end{linenumbers}. Or switch it on %% for the whole article with \linenumbers. \usepackage{lineno} \journal{Fisheries Research} \begin{document} \bibliographystyle{elsarticle-harv} \begin{frontmatter} %% Title, authors and addresses %% use the tnoteref command within \title for footnotes; %% use the tnotetext command for theassociated footnote; %% use the fnref command within \author or \address for footnotes; %% use the fntext command for theassociated footnote; %% use the corref command within \author for corresponding author footnotes; %% use the cortext command for theassociated footnote; %% use the ead command for the email address, %% and the form \ead[url] for the home page: %% \title{Title\tnoteref{label1}} %% \tnotetext[label1]{} %% \author{Name\corref{cor1}\fnref{label2}} %% \ead{email address} %% \ead[url]{home page} %% \fntext[label2]{} %% \cortext[cor1]{} %% \address{Address\fnref{label3}} %% \fntext[label3]{} \title{Agile stock assessment} %% use optional labels to link authors explicitly to addresses: %% \author[label1,label2]{} %% \address[label1]{} %% \address[label2]{} \author{Akira Hayashi, Momoko Ichinokawa, Junji Kinoshita, Akihiro Manabe} \address{ Fisheries Resources Institute, Japan Fisheries Research and Education Agency, 2-12-4 Fuku-ura, Kanazawa ward Yokohama, Kanagawa, Japan 236-8648 } \begin{abstract} %% Text of abstract Stock assessment determines the status of fishery stock to support management decision making. Considering the iterations between exploratory calculations and the need to compare outputs to elicit better model settings, we should focus on not only the accuracy of abundance estimation and the tolerance of uncertainty but also the efficiency of the project workflow. Although in Japan, a stock assessment model was introduced written in the R language in 2012, the workflow did not sufficiently adjust, creating problems because the current workflow is contrary to the principles of effective value creation. To make our project sustainable, we propose adopting the agile methodology, an iterative development method used by software developers, for stock assessment. Therefore, we wrote an example report as a package document in the R language. Developed under a continuous integration environment, the report remains up to date, with every modification on component files. This method enabled our work to be efficient and transparent by allowing and documenting scenario branching, error corrections, and annual updates. We show that the iterative development cycle benefit us by allowing us to focus on the essential business problem of the assessment project. \end{abstract} \begin{keyword} %% keywords here, in the form: keyword \sep keyword agile \sep waterfall \sep build \sep continuous integration \sep reproducible research %% PACS codes here, in the form: \PACS code \sep code %% MSC codes here, in the form: \MSC code \sep code %% or \MSC[2008] code \sep code (2000 is the default) \end{keyword} \end{frontmatter} \linenumbers %% main text \section{Introduction} Stock assessment determines the status of fishery stock to support management decision making. Since calculation results affect management scenarios, the accuracy of abundance estimation and tolerance for uncertainty in future estimations are important. Although assessment models have been improved (reviewed in \cite{methot2009-stock-asses}), there continuously are new requirements for further improvements to model features. However, considering the characteristics of stock assessment\textemdash which requires iterative work between exploratory calculations and the comparison of outputs to elicit better model settings\textemdash technical improvements to model features are insufficient. To better contribute to management, an increase in the efficiency of our project is critically needed. Japanese stock assessment introduced an assessment model written in the R language \cite{team2020-r} from 2012 \cite{ichinokawa2019-stock-japan, ichinokawa2014-review-stock}, However, an incomplete shift in the workflow has been causing problems. Although the production speed of the upstream process has increased thanks to the new assessment model, the processing speed of the downstream process remains low: we still manually paste graphs, tables and type numbers into a report written in word processing software with a graphical user interface (GUI) \cite{hayashi2019-stock-japan}. This mismatch \cite{sharma2017-devop} causes information congestion and lowers project productivity \cite{huang2014-links-between, huang2015-impac-softw}. Manual operation of the GUI word processor impairs not only the speed of iteration but also the quality of the product because manual operations are not reproducible \cite{gandrud2020-reprod-resear}; effort is wasted in recovering the required quality \cite{kano1984-attrac-qualit} of the product at every iteration. The poor productivity of our project is inevitable because our workflow is completely contrary to lean manufacturing \cite{womack2010-lean-think, earley2016-lean-book-lean}, an effective method of value creation. To make our project sustainable, we must adopt a better method. Software development professionals are good at sustainable project management, as they recognized the importance of iterative work for project success early \cite{royce1987-manag-devel} and evolved their developmental method from a slow sequential approach (waterfall methodology, \cite{sommerville1996-softw-proces-model}) to quick iterative approach (agile methodology, \cite{williams2003-guest-editor-introd}). To keep documentation consistent with software behavior, software developers have started generating documents from the source code rather than writing it by hand \cite{forward2002-relev-softw} because they know that documentation that is inconsistent with actual behavior lowers project productivity \cite{kajko-mattsson2005-survey-docum, fluri2007-do-code, ibrahim2012-relat-between, shi2011-empir-study, nuseibeh2000-lever-incon}. Considering that stock assessment projects require both calculations and documentation, there is much to learn from software developers. Even in parallel development, developers keep the directory clean because they work in an isolated workspace utilizing the :``branch'' function of the version control system instead of duplicating files \cite{zolkifli2018-version-contr-system}; This approach is also applicable to exploratory scenario branching in stock assessment. Additionally, their way of using the branch function for debugging was also useful to us. They also focus on converting their tacit knowledge to written programs because they see computer programs as a type of communication \cite{souza2005-study-docum}. Having considered the example of software developers, it is apparent that we should manage stock assessment projects in a sustainable manner. The key to adopting agile methodology (Fig. \ref{fig:agile}) is abandoning the GUI word processor because it forces each process to be run in sequential order\textemdash figures, tables, and calculation results cannot be pasted into the document until the calculation is completed; inevitably, the subsequent processes, such as writing documents, cleaning formats, and discussions on the results, will be blocked (Fig. \ref{fig:waterfall}). The adoption of agile methodology enables assessment projects to adapt to frequent changes in requirements \cite{fitzgerald2000-system-devel-method, roy2018-water-too} during scientific discussions. Making our project buildable is also significant from the viewpoint of reproducible science \cite{leveque2012-reprod-resear}. \begin{figure} \centering \includegraphics[scale=0.3]{agile.pdf} \caption{Conceptual scheme of the agile methodology for stock assessment} \label{fig:agile} \end{figure} \begin{figure} \centering \includegraphics[scale=0.4]{waterfall.pdf} \caption{Conceptual scheme of the waterfall-like workflow for stock assessment due to GUI word processor} \label{fig:waterfall} \end{figure} In this article, we explain how to develop stock assessment as a buildable software product under an agile methodology. We discuss how we developed an assessment report as part of the software and performed a complete process to run at every modification. Our method enabled our work to be efficient and transparent by supporting scenario branching, error corrections, and annual updates. We discuss the effect of the proposed method on stock assessment and demonstrates its significance by relating it with methods in previous studies. \section{Materials and methods} As done in agile methodology, we started our work with the development of a minimum viable product (MVP): a software product that is rough in appearance but works properly \cite{lenarduzzi2016-mvp-explain}. In our case, the MVP is a buildable assessment project from data inclusion to document generation with tentative model settings. An important practice in developing our MVP is continuous integration (CI), which is a system that builds software at every modification \cite{duvall2007-contin-integ}. The essential components of the CI system are i) source codes, ii) the build system, iii) the version control system, and iv) the monitoring system. As an example of stock assessment, sources include both calculations and documentation because the report should contain both the calculation results and narratives. The sources for calculation include files that are needed to reproduce calculation, such as data and source codes written in specific programming language. Speaking of sources for documentation, we have to choose one system that supports the inclusion of external calculation results. \TeX\ has been the de facto standard in the field of technical reporting for a long time. The second element is a server that builds all source files into a product; Thus, the server requires the programming language and documentation system to be installed. All build steps should be written in a build script such as \texttt{Makefile}. The version control system, the third element, is a tool to manage the modification history of every file \cite{swierstra2014-seman-version-contr}. The final element is a monitoring system that triggers building in linkage with the version control system. Jenkins \footnote{\url{https://www.jenkins.io}} is a widely used software for this use. The other option available is hosting services such as Travis CI \footnote{\url{https://travis-ci.com}}, Circle CI \footnote{\url{https://circleci.com}}, GitHub Actions \footnote{\url{https://github.com/features/actions}}, and so on. Although we can set up a CI document system independent of programming language, We think R language and its general document system Rmarkdown \cite{allaire2020, xie2018-r-markd} are good candidates. Using R language, we can integrate the sources for calculation and documentation into a single \texttt{.Rmd} file with the deployment process automated by a GitHub workflow using the R package \texttt{pkgdown}. The GitHub workflow renders our \texttt{.Rmd} into \texttt{.html} and deploys the product to the website. Here, tables are supported by a package \texttt{knitr}, so writing additional code snippets to generate tables is not necessary. These features will provide scientists engaging stock assessment with a good writing experience regardless of the programming language they use for the main calculation. \subsection{Buildable assessment project under CI system} To present a document consistent with the calculation, we bundled our sample report as a software package written in R language. In general, there are two types of motivation to develop the R package: i) to provide end-users specific calculation routines and ii) to robustize the work of the developer's own; The motivation of this work corresponds to the latter. This article does not instruct the basic method to develop the R package because a detailed instruction is available \cite{hadley2015-r-packag}. Instead, we explained how to deal with situations frequently occurring in reporting stock assessment---handling scenario branching, debugging after discussion, and managing annual updates. We implemented our project following the basic directory structure of the R package (Fig. \ref{fig:components}). An Rmarkdown file \texttt{report. Rmd} was created under directory \texttt{vignettes/}. The report can be built by the function \texttt{build()} of package \texttt{devtools}. In the following section, we express the call of \texttt{some\_function()} of the R package \texttt{some\_package} as \texttt{some\_package::some\_function()}. \begin{figure} \centering \includegraphics[scale=0.9]{components.pdf} \caption{Directory structure of the example package} \label{fig:components} \end{figure} Following test-driven development \cite{beck2003test}, we started the implementation by writing test code; we wrote tests for \texttt{load\_data()}, \texttt{calculate()}, \texttt{diagnose()}, and \texttt{visualize()} under directory \texttt{test/testthat/}, which were initially failed because the functions were non-existent. After specifying the behavior of the functions within the test, we implemented these four functions under the directory \texttt{R/} to pass the tests. After confirming that the new functions passed all the tests, we called them in \texttt{report. Rmd} following functional programming: R objects were not created because all functions are relayed by pipe operators. Our actions in this project are expressed by the program itself, written in the report\textemdash\texttt{load\_data()}, \texttt{calculate()}, \texttt{diagnose()}, and \texttt{visualize()}. Every time we call \texttt{devtools::build()}, all tests are executed, and the report is updated, with the most recent calculation results embedded. Continuous integration systems were established to automate the build process. We chose Git \footnote{\url{https://git-scm.com}} for the version control engine. To store all the code, we created a repository named \texttt{saaas} (Stock Assessment As A Software) \cite{hayashi2020-stock-asses} on the Git hosting service GitHub \footnote{\url{https://github.com}}. After ``committing'' our work, we ``pushed'' it to the repository (Table \ref{table:def_vcs}). The builds ran on a virtual Microsoft Azure machine \footnote{\url{https://docs.github.com/en/actions/reference/virtual-environments-for-github-hosted-runners}} because we used GitHub Actions to manage the CI system. We chose GitHub Pages \footnote{\url{https://pages.github.com}} to host the build result. \begin{table} \caption{Definition of terms in the version control system} \label{table:def_vcs} \begin{center} \begin{tabular}{ll} \toprule \multicolumn{1}{c}{Term} & \multicolumn{1}{c}{Definition} \\ \midrule commit & to register a modification to files in the version control system \\ push & to send commits to the repository \\ merge & to apply a change to one specific branch(es) to another \\ revert & to cancel modification of the specific commit(s) \\ rebase & to transplant one specific branch onto another branch \\ \bottomrule \end{tabular} \end{center} \end{table} At this point, we have succeeded in creating our MVP. Although our MVP is too simple for actual use, we can now improve it in an iterative manner because every modification to the source files will be reflected in the report hosted on GitHub Pages. \subsection{Issue tracking system} All work should be based on issues \cite{kaminski2008-relat-probl}, which are a list of ideas, problems, enhancements, tasks, and bug reports. Every issue should be managed by focusing on the following points: i) when the issue is recognized and ii) how is it resolved. Thus, we need an issue tracking system to manage tasks for the improvement of our product. In this paper, we used GitHub as an issue tracking system. In the following sections, we explain our work within each iteration. Here, we use the term ``iteration'' to express the following set of work steps done in an issue-driven manner \cite{hall2008-probl-orien}: i) define issue and create a new branch to resolve it, ii) update code, iii) commit and push, and iv) apply modification to the repository after comparison with the original. \section{Iterations} \subsection{First iteration: scenario branching} In the first iteration, we will show how scenario branching can be handled in a continuous documentation workflow. The first example issue of our project is ``What will happen to stock abundance if the assumption on recent selectivity is modified?''%Editor: Please ensure that the intended meaning has been maintained in this edit. \subsubsection{Materials and methods} The aim of this section is to handle branched scenarios with different settings. To modify the source code independently of the original version, we use the branch function of Git. The branch, like a branch of a tree from the main stem, is a parallel world of the workspace originating from a certain point in the original workspace. From \texttt{master}, the original branch, we created three branches---\texttt{branch\_a}, \texttt{branch\_b}, and \texttt{branch\_c}---and modified the model settings on each branch. After committing the modifications, we push them to GitHub. To enable comparison between branches, we have to upload the build results elsewhere; We used the Simple Storage Service (S3) of Amazon Web Service (AWS) for the output storage. We modified \texttt{visualize()} to export the calculation output as \texttt{result.csv} and created a GitHub Actions workflow to upload \texttt{results.csv} to S3 at every build. To compare these results with the original scenario, we updated \texttt{visualize()} to draw calculation results for each scenario. The modified version of \texttt{visualize()} showed the difference between the current calculation and the result generated from specific branches. We also updated the GitHub Actions workflow to upload the rendered \texttt{report.html} to S3. Next, we updated the argument of \texttt{visualize()} to compare the outputs with those from \texttt{master} and then opened a pull request from each branch to \texttt{master}. Due to the time order of the work, we compared all four branches on the pull request from \texttt{branch\_c} to \texttt{master}. On the pull request referencing the current issue, we discussed the comparison and determined which scenario to choose, accepting \texttt{branch\_a} and rejecting the other scenarios. \subsubsection{Results and brief discussion} The branch system enables us to handle multiple scenarios without cluttering the working directory. In the pull request, we can review not only the difference in code between scenarios but also conversations regarding the request to merge (Table \ref{table:def_vcs}) scenarios. We can trace how the project has evolved to the current state; the branch network shows how many scenarios have been considered and why each scenario was accepted or rejected. Thus, our method made the decision-making process traceable in future retrospective projects. From the viewpoint of artifact management \cite{hoek1997-softw-releas-manag}, the generated files should maintain a one-to-one correspondence with their source code. To avoid human error originating from manual operations, we ignored build artifacts such as \texttt{report.html} and \texttt{results.csv}; we committed only source files such as \texttt{report. Rmd} and R code under \texttt{R/}. Without manual operation, these artifacts were generated on the build server and sent to cloud storage for scenario comparison. By utilizing CI, we can focus our effort on the essential intellectual work. \subsection{Second Iteration: bugfix} What should we do if we find some bugs that affect all of the scenarios compared in the last iteration? Do we have to fix the bugs on all branches by hand?\textemdash\ The branch system also provides an effective solution in this situation. To simulate the situation, assume that there is a bug in the catch data: the demo issue for this iteration is ``Fix a bug in catch data''. \subsubsection{Materials and methods} To recompare the scenarios after bugfix, we reverted (Table \ref{table:def_vcs}) the merge commit on the \texttt{master} branch, which brings the status back to the earlier status before merging (Fig \ref{fig:revert}). Following the conventional approach with bugfix, we created a branch named \texttt{hotfix} from \texttt{master}. On \texttt{hotfix}, we added a test to detect the bug, confirmed that the new test breaks the build, and then corrected the catch data to fix the build (Fig. \ref{fig:rebase}, left). After fixing the bug on \texttt{master} by merging the pull request from \texttt{hotfix} to \texttt{master} (Fig. \ref{fig:rebase}, middle), we rebased (Table \ref{table:def_vcs}) the three scenario branches on \texttt{master} to apply the same bugfix (Fig. \ref{fig:rebase}, right). We force-pushed the rebased branches because the default command cannot push a branch with a revised modification history. Referring to the current issue number, we reopened the pull requests to \texttt{master} from each scenario branch and recompared the build outputs. Following the same procedures followed in the previous iteration, \texttt{branch\_a} was accepted and merged into \texttt{master}. \begin{figure} \centering \includegraphics[scale=0.3]{revert.pdf} \caption{Reverting the merge commit on \texttt{master} to cancel the modification added by \texttt{branch\_a}} \label{fig:revert} \end{figure} \begin{figure} \centering \includegraphics[scale=0.3]{rebase.pdf} \caption{Bugfix of scenario branches by rebasing} \label{fig:rebase} \end{figure} \subsubsection{Results and brief discussion} Using the rebase function of Git, we enabled reassessment of the scenario branches after bugfix was applied. Although merging could also be used to apply bugfix to the scenario branches, rebasing is appropriate in this situation because it can overwrite commit history: if we had used the merge function to apply bugfix, the final commit of each branch would be bugfix and would mask the important commit comparison on the pull request (Fig. \ref{fig:merge}). Rebasing kept the branch network clean and rational and enabled us to focus on the essential differences between branches. \begin{figure} \centering \includegraphics[scale=0.3]{merge.pdf} \caption{Complicated commit history after merging \texttt{hotfix} into scenario branches} \label{fig:merge} \end{figure} \subsection{Third Iteration: clarify tacit knowledge} We continued to update the stock assessment. However, we had hard-coded the value of the argument \texttt{year} inside the software but still had not clarified our tacit knowledge on the consistency of years between the data and the calculations: our calculation uses data from one year prior to the assessment, but this ``knowledge'' cannot be executed because it is not expressed as working code. Thus, the system is not fully self-documented in terms of its maintainability between years. The example issue for this iteration is ``clarify the intended one-year lag between data and calculations.'' \subsubsection{Materials and methods} We created a function \texttt{metadata()} that contains the metadata of the project such as species name, stock name, and year. Then, we added a test that confirms the consistency between the years of the data and those of the metadata. Since our calculation uses data from one year prior to the assessment, we had to confirm that the lag in years between the data and the metadata equals one. We simplified our functions using \texttt{metadata()}: we replaced the argument \texttt{year} of \texttt{fcurrent\_years()} and \texttt{terminal\_f\_years()} with \texttt{metadata()} for the year reference; then, the function \texttt{calculate()} became free from the argument \texttt{year}. Next, we implemented tests for species name and year of the \texttt{metadata}, which work as system tests. \subsubsection{Results and brief discussion} By adding system tests, we managed to confirm the overall consistency of the software. Whenever we run \texttt{devtools::test()}, all tests are run, and the result confirms that everything has gone well. Implementing such a system test will drive future updates to be consistent; when we incremented the test year to \texttt{2019} to simulate an update in the next year, the test failed because the year given to the test is different from that in the \texttt{metadata()}. To fix this test, we have to increment the year in the \texttt{metadata()}. Following this fix, another test fails because the year values for the \texttt{metadata()} and those for the data differ. To fix this test, we have to add data from 2019. After all the fixes, when all the tests as passed, project updating is completed with quality assurance. \section{Discussion} In the present study, we showed how to develop a stock assessment project as software. Because we implemented the report as a buildable document under the CI system, every update to the source files triggered a build on a cloud computer that uploaded the report in html format to online storage. This keeps our document up to date with the source code and data. In the present paper, we followed the standard development procedure for generic software and the R package \cite{hadley2015-r-packag}. The standardized procedure helped us to maintain a clean project. We also implemented modularized functions under a directory with a standard structure. The organization of the program and directory was maintained because we branched our scenario using a version control system. Issue-driven iterative development \cite{hall2008-probl-orien} made our work traceable as it related to specific issues. The branch-based workflow allowed us to compare multiple scenarios on pull requests and to review all decision-making processes; it also helped us to correct fundamental defects even after scenario branching. By clarifying our tacit knowledge about the year lag between data and assessment, we made our software maintainable for future updates. The method we propose can not only speed up the calculation-communication cycle of stock assessment but also ensure the stability of the project. To support sustainable fishery management, we, the scientists engaging in stock assessment, also need to make our working methods sustainable. \subsection{Lean documentation} The essence of stock assessment is value creation. Spotlighting this aspect of our role, we applied lean manufacturing \cite{womack2010-lean-think, earley2016-lean-book-lean}, a proven method in many business domains, to the documentation of stock assessment. Despite originating in the car industry, lean manufacturing has been applied to other fields of manufacturing, including software development \cite{alves2015-produc-system, alves2014-the-lean} due to its general effectiveness for value creation. Our method complies with the five principles of lean manufacturing: (1) specify value, (2) identify the value stream, (3) flow, (4) pull, and (5) pursue perfection. The value of a project must be distinguished from its product; it is the customer satisfaction provided by the product. Taking the car industry as an example, the value is not the car itself but the pleasurable experience brought by driving the car. The value that stock assessment provides to management is a smooth decision-making process, which is provided by the product: a comprehensible assessment report. All of our work contributes to customer value because we arranged the value stream, the focus of the second principle. The value stream is all the actions that are needed to provide value to the customer. At the beginning of the first iteration, we built a CI documentation system that converts our work to improve customer value. Our only task is to edit source code, commit our work, and push it to GitHub. Committing is not a task without value; it works as an input control for the quality of the work. Once the modification is registered as a commit, there is no room for human error because all subsequent processes are automated. The third principle ``flow'' is about keeping the process moving at a steady pace from start to finish \cite{earley2016-lean-book-lean}. This principle emphasizes the importance of a steady, not an as-fast-as-possible, pace. Our CI system, which stops product delivery if even a small typo exists in the code, follows the flow principle. From a myopic viewpoint, a workflow that does not allow any defects may seem vulnerable compared to that based on the GUI word processor, but our CI system prevents a pile of small deficits from building up after several time lags and causing severe problems; bugs should be removed at the moment they are introduced because the cost of debugging increases with time. A successful build proves that the issue, which arose from user requirements, was converted into value without problems. The fourth principle, ``pull'', is achieved by our coding style. To eliminate the goods-in-process that do not contribute to value, every process should be suspended until the next production process pulls its result. The techniques that contribute to these principles are test-driven development and functional programming. Test-driven development is a technique to start coding from a test to ensure that the code fails the test properly \cite{beck2003test}. Although the famous benefit of test-driven development is that it helps clarify the behavior of the program component, it has another benefit in terms of lean production: the failing test we wrote at the beginning of each iteration works as a ``pull'', telling us that the latter process requires the new function. This method prevents us from writing not only programs without tests but also unnecessary programs. Functional programming---a technique that designs a program to use the return of other function rather than an object state---also commits to the pull principle. Without creating any R object in the report, we converted data into value with functions in a single flow using a pipe operator. This means that we constructed our program based on ``pull'' from the previous function. Programs with minimum side effects keep us from cluttering our directory with goods-in-process files. The last principle, ``perfection,'' is a continuous ``kaizen'' attitude towards user satisfaction. Although our report is simplified for demonstration, it can be improved without degradation of the product quality because the framework we created enables our direct commitment to the user value. To increase project productivity, it is necessary to not only increase the speed of improvement but also avoid regressions. We also suppressed the recurrence of a bug by adding a test. These small but steady incremental improvements are necessary for project stability. The workflow proposed here is not the sole solution for every project: workflows should be designed considering the context of the project, such as the skill levels of those involved and the available tools. Nevertheless, following the lean principles helped us to design an effective workflow, and it has proven to be successful in varying business domains \cite{alves2014-the-lean}. \subsection{Lessons from the history of software development} Our novel approach to stock assessment was influenced by our knowledge of software development. The more our work relies on the computer, the more similar the problems we face become to those that software developers have already addressed. When we stuck to the area of our own expertise, we were unable find a good exemplar to solve our problem. Although the field of software development varies, software developers have compiled excellent methodologies for information management because they focus on abstracting problems into their essence. With this ability, software developers can employ knowledge beyond the field of their expertise. The practices of developers such as CI offer general advantages to work that involves computers: repeatability, reliability, recoverability, and so on. Such ``ilities'' \cite{bass2015-devop-soft-archi} allow us to focus on essential business problems. Developing reports under the CI system will bring benefits to not only scientists but also model programmers. When trying to resolve technical problems such as model features and interfaces, we need effective communication; miscommunication during the specification is one of the major factors lowering project productivity \cite{kortum2016-miscom-softw-projec}. Behavior-driven development \cite{pereira2018-behav-driven, scandaroli2019-behav-driven} is recognized to be a solution to this issue. Communication based on documents generated by the CI system and its source code works as form of behavior-driven development, and it helps to avoid miscommunication because everyone sees exactly the same behavior in the rendered report on the cloud server. Our method provides benefit in the context of knowledge management \cite{lethbridge1992-beyon-hyper}. Code is not only a source of value creation but also a form of communication between the project members \cite{souza2005-study-docum} because the source code is the only accurate description of the software \cite{souza2005-study-docum, mcconnell2004-code-compl}. Since literate programming enables reporting based on the source code, the writing procedure as a visible code is repeatable because it is executable by any person. As a result, making the procedure visible helps find errors as well. We have tacit expectations for not only our procedure but also our data. We can make our expectations visible by writing tests that allow us to focus on unusual data as well, such as unbelievably low or high amounts. The accumulation of explicit knowledge leads to the building of a knowledge base, which will have strong appeal in the case of peer review of stock assessment. The standardization of the method eliminates project-specific rules and methodologies. We developed our program as an R package, which standardizes our program and makes it comprehensible among the R user community. Standardization distinguishes essential differences in business knowledge between projects. Although our method required us to learn how to develop an R package, the technique can be applied to other projects and bring the benefit of organized workflows. \subsection{Future perspective} In this article, we defined our user as management. We confess that this definition was so arbitrary that we premised the development of a report as our product. The lean principle suggests that the proper definition of the end user is indispensable for business success; without proper end-user definition, value is distorted by the middle of the organization because it adds complexity of no interest to the end-user \cite{womack2010-lean-think}. For successful value creation, we must realize who our true end-user is. Stock assessment is part of a stratified business activity: fishery scientists give management an assessment report to support smooth decision making; management gives the fishing industry a fishing policy to provide sustainable fisheries. Hence, our true end-users are those people who expect sustainable fishery management to maintain their fishery business and consumption activity. In other words, the scientists engaging in stock assessments, the people in fishery management, and the people working in the fishery industry are the co-creators of sustainable fisheries. Considering our true purpose, value co-creation, the tool we need is not a report, but a business intelligence (BI) tool \cite{carvalho2016-busin-intel, hippel2001-persp} that supports discussion between co-creators. Putting into words, the BI tool in stock management will provide stock assessment as a service. This expectation is inferred by the trend of servicification in the software business, which has persisted since the 2010s. Although the closest example is the ``Assessment Tools'' \footnote{\url{https://www.ices.dk/data/assessment-tools/Pages/default.aspx}} hosted by the International Council for the Exploration of the Sea (ICES), no BI tool targeting managemental discussion has been developed at this time. BI tool platforms such as the R package Shiny \footnote{\url{https://shiny.rstudio.com}} and the commercial service Tableau \footnote{\url{https://www.tableau.com}} will help us build our own BI tools, and cloud computing services such as AWS and Google Cloud Platform \footnote{\url{https://cloud.google.com/gcp/}} will provide us with an environment for establishing microservice architectures from scratch. If our future BI tool includes narratives, it should be served by an independent MS service; this will solve a weakness of the proposed method: the time cost of the entire build is triggered by a small modification of narratives. We recognize the imperfection of a report as a product for higher end-user experience. However, as a small step towards change in the business model, we introduced a method to resolve the methodological problems of the current stock assessment project. Not only technical but also cultural aspects are a major problem in the transformation of workflows \cite{pechau2011-raftin-agile-water}; even in the software industry, the migration to agile methodology is difficult for projects traditionally managed by the waterfall methodology \cite{kusters2017-when-agile, theocharis2015-is-water, kuhrmann2017-hybrid-softw, theobald2018-inter-probl, clear2003-water-is-dead}. Although build-based documentation requires a cultural shift for projects away from using the GUI word processor, the investment will pay off because stock assessment is a continuous project. The method can be applied to all projects, not only stock assessment but also other research activities. %% The Appendices part is started with the command \appendix; %% appendix sections are then done as normal sections %% \appendix \bibliography{refs} %% The Appendices part is started with the command \appendix; %% appendix sections are then done as normal sections %% \appendix \end{document} \endinput %% %% End of file `elsarticle-template-harv.tex'.