Download as
Browse Code »

Commit 7993fa1ea3a4fa07b87d4236a1a4a473e438e086

Authored by Melissa Wen
1 parent 2e929423
Exists in master and in 3 other branches oss_2018, oss_2018_siqueira, rework_case_study

[oss-2018] review

Showing 5 changed files with 78 additions and 215 deletions   Show diff stats
icse2018/content/00-abstract.tex
  Diff comments   View file @7993fa1
1 1 \begin{abstract}
2 2  
3   -TO-DO
4   -
5   -...
6   -
7   -...
8   -
9   -...
10   -
11   -...
12   -
  3 +In this paper, we examined the case of a 30-month government-academia development collaboration to map open source practices that reconciled the differences in software project management on both sides. We evidence the practices adopted from the data collected on the repository management tool of the developed platform itself. The benefits of the empirical management model created in this project are revealed by the results of surveys with participants on both sides of the project. These results suggest the adoption of open source practices to improve the software development in context with diversity of organizational culture and people mind-set.
13 4  
14 5 \end{abstract}
15 6  
... ...
icse2018/content/01-introduction.tex
  Diff comments   View file @7993fa1
1 1 \section{Introduction}
2 2  
3 3 E-government projects differ from others due to their complexity and
4   -extension\cite{anthopoulos2016egovernment}. They are extensive in terms of
5   -organizational size, time, scope, target audience and corresponding resistance
6   -to change. They are also complex by combining Construction, Innovation and Information and Communications Technologies
7   -in their context, in addition to politics and social impact. To create novelty for e-government projects and meet the needs of society, research
8   -collaboration between government and academia can be considered as a way to
9   -transfer technological knowledge. However, such collaboration also has
10   -challenges, not only in relation to project organization and alignment of goals
11   -and pace \cite{sandberg2017iacollaboration}, but also to overcome the failure
  4 +extension\cite{anthopoulos2016egovernment}. They are complex because they combine construction, innovation, information \& communications technologies, politics and social impact. Their extension, on the other hand, is related to their scope, target audience, organizational size, time and the corresponding resistance
  5 +to change. Government-academia researches can be considered a way to create novelty for e-government projects and to meet the needs of society. However, this collaborative work also has challenges, such as to organize the project, to align goals, to synchronize the pace of both sides\cite{sandberg2017iacollaboration}, and to overcome the failure
12 6 trend of e-government projects \cite{goldfinch2007pessimism}.
13 7  
14   -Poor project management is one of the top failure reasons of
15   -e-government projects \cite{anthopoulos2016egovernment}. In Brazil, while
16   -industry and academia prefer agile approach to manage their projects, -
17   -characterized by people-oriented approach
18   -\cite{highsmith2001agileSoftwareDevelopment}, the collaboration with clients
19   -\cite{fowler2001newMethod}, small self-organized teams
20   -\cite{cockburn2001peopleFactor}, and the flexibility regarding planning
21   -\cite{highsmith2002agileEco} - the government culturally uses traditional
22   -methods to discipline its software development process - focused on
23   -documentation, processes oriented, and heavily based on tools
24   -\cite{awad2005comparisonAgileTrad}. When government and academia decide to
25   -come together for the development of an e-government solution, management
26   -processes of each institution needs to be aligned. Changing the software
27   -development process represents a complex organizational change that
28   -impact several aspects such as structure, culture, and management practices
29   -\cite{nerur2015challenges}. However, neither culture nor values can be
30   -easily change and the effort for this kind of movement does not seem
31   -feasible for development projects with tight deadlines and budgets.
  8 +Poor project management is one of the main reasons why
  9 +e-government projects fail\cite{anthopoulos2016egovernment}. In Brazil, while
  10 +industry and academia prefer agile approaches to manage their projects, government organizations generally use traditional
  11 +methods to discipline its software development. When government and academia decide to
  12 +join forces to develop an e-government solution, these differences in project management become an issue. Changing the software
  13 +development process in a large-size institution represents a complex organizational change that has impacts on structure, culture, and management practices \cite{nerur2015challenges}. Therefore the effort for this kind of movement does not seem
  14 +feasible for projects with tight deadlines and budgets.
32 15  
33   -This paper presents practical ways of harmonizing project management process
34   -differences existing between government and academia based on free software
35   -development practices. For this, we interviewed members involved in the project
36   -with distinct roles: requirement analysts of the Brazilian Ministry of Planning
37   -(MPOG), interns of the University of Brasília and University of São Paulo, and
38   -senior developers. We also analyze data collected from the management and
39   -communication tools. With these results, we evidence best practices adopted on a
40   -30-months project to create an unprecedented platform for the Brazilian
41   -government. Finally, we compare briefly the results of this current work to the
42   -lessons learned reported in our previous work.\cite{meirelles2017spb}.
  16 +This paper presents open source practices adopted to harmonize differences between government and academia project management. By examining a 30-month government-academia collaboration case, we map
  17 +the management practices of the referred project and show their benefits, using collected data from repository management tools and surveys with project participants of both sides: analysts from the Brazilian Ministry of Planning (MPOG) and developers from the University of Brasília and the University of São Paulo. At the end, we compare the results of this current work with the
  18 +lessons learned and reported in a previous paper\cite{meirelles2017spb}.
43 19  
44 20 Section \ref{sec:relatedwork} describes related work. Section
45 21 \ref{sec:researchdesign} describes our research questions and research
... ...
icse2018/content/04-methods.tex
  Diff comments   View file @7993fa1
1 1 \section{Research Design}
2 2 \label{sec:researchdesign}
3 3  
4   -The focus on this paper is finding practical ways to reconcile cultural
5   -differences in software development between academia and government,
  4 +The focus on this paper is investigating practical ways to reconcile cultural
  5 +differences in software development process between academia and government,
6 6 without modifying their internal processes. Our analysis was guided by the
7 7 following research questions:
8 8  
9   -\textbf{RQ1.}{What practices based on open source development experiences would
  9 +\textbf{RQ1.}\textit{What practices based on open source development experiences would
10 10 help to combine teams with different management processes in a
11 11 government-academia collaboration project?}
12 12  
13 13  
14   -\textbf{RQ2.}{How do open source development practices benefit the process of
  14 +\textbf{RQ2.}\textit{How do open source development practices benefit the process of
15 15 developing an e-government platform in a government-academia collaboration?}
16 16  
17 17 To answer these questions, we use as a case study the evolution project of the
18   -SPB portal \cite{meirelles2017spb}, a government and academia collaborative
  18 +SPB portal \cite{meirelles2017spb}, a government-academia collaborative
19 19 development based on open source software integration. We designed two surveys
20   -and an interview aimed at the different roles performed by the ex-project
  20 +and an interview to the different roles performed by the ex-project
21 21 participants and collect public data from the project development environment
22 22 available on the developed platform itself. Our research approach is detailed
23 23 in the following subsections.
24 24  
25   -\subsection{The case estudy}
  25 +\subsection{The case study}
26 26  
27 27 The project to evolve the Brazilian Public Software Portal
28   -\cite{meirelles2017spb} was a partnership between government and academia held
29   -between 2014 and 2016. To solve maintenance problems and fill
  28 +was a partnership between government and academia held
  29 +between 2014 and 2016\cite{meirelles2017spb}. To solve maintenance problems and fill
30 30 design-reality gaps in the portal, the Ministry of Planning (MPOG) joined the
31 31 University of Brasília (UnB) and the University of São Paulo (USP) to develop a
32   -platform based on the integration and evolution of existing open-source
33   -software, with many features and technologies novelties in the government
34   -context.
  32 +platform based on the integration and evolution of five existing open source
  33 +software.this environment was a novelty in the context of the Brazilian government, due to the technologies employed and its diverse features, including social networking (Noosfero), mailing lists (MailMan), version control system (GitLab), and source code quality monitoring (Mezuro), all integrated using a system-of-systems software (Colab).
35 34  
36 35 The academic team carried out development activities in the Advanced Laboratory
37   -of Production, Research and Innovation in Software Engineering (LAPPIS) of UnB.
  36 +of Production, Research and Innovation in Software Engineering (LAPPIS) at UnB.
38 37 The project management and development process in this laboratory is usually
39   -executed adopting free software practices and agile approach. For this project,
40   -a total of 42 undergraduate students, two MSc students and two
41   -coordinator-professors participated in the development team. Six IT
42   -professionals were also hired as senior developers due their vast experiences in
43   -Front-end/UX or in one of the softwares integrated to the platform.
44   -
45   -The government team was composed of a director, a coordinator, and two IT
46   -analysts from a department of MPOG. Although it was responsible for the
47   -execution of this collaboration project, this department generally does not
48   -execute development of ministry's software. This department is responsible for
49   -contracting and homologating software development services and follows
50   -traditional management approaches, such as the RUP.
  38 +executed adopting empirical practices from open source communities and agile methodologies. For this project,
  39 +a total of 42 undergraduate students and two coordinator-professors participated in the development team. Six IT professionals were also hired as senior developers due their experiences in open source projects and two designers specialized in User eXperience.
51 40  
  41 +The government team was composed of one director, one coordinator, and two IT
  42 +analysts from a department of MPOG. Although they were responsible for the
  43 +execution of this collaboration, their department generally does not
  44 +execute development of ministry's software, its responsibility is
  45 +contracting and homologating software development services, following
  46 +traditional management approaches, such as the RUP, CMMI, and PMBOK.
  47 +
  48 +% Conteúdo OK melhorar construção
52 49 These two aforementioned teams periodically met in person for the purpose of
53   -managing the project progress. These meetings initially only took place at the
54   -ministry's headquarters to discuss strategic/political and technical goals.
55   -These meetings were held monthly with the presence of two UnB professors, the
56   -executive-secretary of the Presidency (project supporter) and all MPOG members
57   -responsible for the project. The management of the development team was
58   -concentrated in the academia side. The workflow was organized in Redmine in
59   -biweekly sprints and 4-month releases, with intermediate deliveries hosted in
60   -university environment. However, with the progress of the project, this format
61   -proved to be inefficient. Conflicts between the internal management processes
  50 +managing the project progress, discussing strategic/political and technical goals. Initially, these meetings took place at the ministry's headquarters and, usually, only directors and professors participated. The management of the development team was
  51 +concentrated in the academic side and was organized in
  52 +biweekly sprints and 4-month releases. However, with the progress of the project, this workflow proved to be inefficient. Conflicts between the internal management processes
62 53 and differences in pace and goals of each institution were compromising the
63 54 platform development.
64 55  
65 56 \subsection{Survey and data collection}
66 57  
67   -We divided the UnB development team into two groups of respondents according to
68   -their roles during the project: UnB Interns and Senior Developers. For each
  58 +We divided the UnB development team into two groups of target participants according to
  59 +their roles during the project: \textit{UnB Interns} and \textit{Senior Developers}. For each
69 60 group, we designed an online survey with topics related to project organization,
70 61 development process, communication and relationship between members, acquired
71   -knowledge and experience with free software. We also interviewed two MPOG
72   -analysts who directly interacted with the development team and project
  62 +knowledge and experience with free software. We also interviewed two \textit{MPOG
  63 +analysts} who directly interacted with the development team and project
73 64 development process. The interview questions could be classified into four
74 65 parts: Professional profile; Organization, communication and development
75 66 methodologies in the context of government and project; Satisfaction with the
76 67 developed platform; Lessons learned.
77 68  
78   -\begin{enumerate}
79   - \item \textit{UnB interns:} We sent the link of the online survey through
80   -emails to 42 undergraduate students who participated in any time of the project
  69 +We sent the link of the online survey through emails to 42 UnB interns (undergraduate students), who participated in any time of the project
81 70 as developer receiving scholarship. We received a total of 37 responses. Their
82 71 average age is 25 years old and 91.9\% of them are male. Currently, 35.1\%
83 72 continue at university as undergraduate or graduate students, 18.9\% work as
... ... @@ -86,9 +75,7 @@ entrepreneurs, 8.1\% are unemployed and the others work as teachers or civil
86 75 servants. 43.2\% said the SPB project was their first experience with free
87 76 software.
88 77  
89   - \item \textit{Senior Developers:} We also sent the link of the online survey
90   -through emails to eight advanced level researchers (MSc students or IT market
91   -professionals who participated in some period of the project). All of them
  78 +We also sent the link of the online survey through emails to eight senior developers (IT market professionals). All of them
92 79 answered the questionnaire. Their average age is 32 years old and 87.5\% are
93 80 male. They have an average of 11 years of experience in the IT market, and
94 81 currently 62.5\% of respondents are company employees, 37.5\% are freelance
... ... @@ -97,21 +84,19 @@ worked on average in 5 companies and participated in 4 to 80 projects. They
97 84 participated in this collaborative project between 7 to 24 months. 85.7\% of
98 85 them had some experience with free software before the SPB project.
99 86  
100   - \item \textit{MPOG Analysts:} two MPOG IT analysts were interviewed separately.
  87 +Two MPOG IT analysts were interviewed separately.
101 88 Each interview took an average of 2 hours with 28 open questions. They are more
102 89 than 30 years old and have been government employees for more than 7 years.
103 90 Only one of them continues working in the same ministry. For both, this
104 91 collaborative project was their first experience of government-academia
105 92 development collaboration.
106   -\end{enumerate}
107 93  
108 94 Finally, we quantitatively analyze data about the development of the project,
109   -publicly available on the SPB platform. We collected from the repository manager
110   -of the platform, Gitlab - integrated platform software tool, all open issues
111   -and commits made between April 2015 to February 2016 and related to the
112   -main repository of the platform, that is, the development repositories of the
113   -integrated software were not considered. For issues, the data collected were:
114   -project name, author of the issue, opening date, issue title and number of
  95 +publicly available on the SPB platform. We collected from the repository manager tool of the platform all open issues and commits related to the main repository of the platform, that is, the development repositories of the integrated software were not considered.
  96 +For issues, we collected:
  97 +project name, author of the issue, opening date, issue title, and number of
115 98 comments. We also collected informations about: total open issues, total
116 99 commits, different authors of issues, total of different authors of issues,
117   -total of comments, authors of comments, total of authors other than comments.
  100 +total of comments, authors of comments, total of authors other than comments.
  101 +During the period from April 2015 to June 2016, 879 issues was opened by 59 distinct authors with a total of 4658 comments and 64 distinct commentators. The development team made 3256 commits in the repository provided by SPB platform, the first one in July 2014 and the last one in August 2016.
  102 +
... ...
icse2018/content/05-results.tex
  Diff comments   View file @7993fa1
... ... @@ -12,62 +12,7 @@ At the end of the project, an empirical
12 12 model of management and development process was created by aligning experiences
13 13 from the FLOSS universe, academic research and bureaucracies needed by the
14 14 government. In this section, we present by context the practices adopted in this
15   -second phase and show the benefits generated by its deployment, as summarized
16   -in the Table \ref{practices-table}.
17   -
18   -%% TODO: explicar a estrutura e cada campo da tabela
19   -
20   -\begin{table}[]
21   -\centering
22   -\resizebox{\textwidth}{!}{%
23   -\begin{tabular}{ | m{4cm} m{10cm} m{10cm} | }
24   -\hline
25   -\textbf{Decision} & \textbf{Practice Explanation} & \textbf{Benefits} \\ \hline
26   -\textbf{Project management and communication on the developing platform itself}
27   -&
28   -\begin{itemize}
29   -\item Migration of project management and communication into
30   -the platform under development using its integrated software components Gitlab
31   -and Mailman
32   -\end{itemize} &
33   -\begin{itemize}
34   -\item Trusting developed code;
35   -\item Communicating with transparency and efficiency;
36   -\item Easier monitoring and increasing interactions between development team and public servants;
37   -\item Producting organically documentation and records;
38   -\end{itemize} \\ \hline
39   -
40   -\textbf{Bring together government staff and development team} &
41   -\begin{itemize}
42   -\item Biweekly gov staff, senior developers and coaches met to planning and
43   -review sprint at the UnB headquarters. \item Most of features under development
44   -were discussed on Gitlab Issue Tracker. \item Only strategic decisions or
45   -bureaucratic issues involve board directors. \item Continuous Delivery
46   -\end{itemize} &
47   -\begin{itemize}
48   -\item Reducing communication misunderstood and better meeting expectations of both sides;
49   -\item Overcoming the government bias regarding low productivity of collaboration with academia;
50   -\item Aligning both activities execution pace;
51   -\item Improving the translation of the process from one side to the other;
52   -\end{itemize} \\ \hline
53   -
54   -\textbf{Split development team into priority work fronts with IT market specialists} &
55   -\begin{itemize}
56   -\item The development was divided into four fronts (DevOps / UX / Noosfero / Colab) with a certain self-organization of tasks.
57   -\item IT market professionals with recognized experience on each front were hired to work in person or remotely.
58   -\item For each front, there was at least one senior developer and the role of coach.
59   -\item The meta-coach role was also defined to coordinate tasks between teams.
60   -\end{itemize} &
61   -\begin{itemize}
62   -\item Helping to reconciliate development processes and decision-making;
63   -\item Creating support-points for students, senior developers, and gov staff;
64   -\item Transfering of knowledge from industry and FLOSS community to both academia and government;
65   -\end{itemize}\\ \hline
66   -\end{tabular}%
67   -}
68   -\caption{Empirical SPB management method and its benefits}
69   -\label{practices-table}
70   -\end{table}
  15 +second phase and show the benefits generated by its deployment.
71 16  
72 17 \subsection{Project management and communication on the developing platform
73 18 itself}
... ... @@ -96,13 +41,11 @@ know something, could go there and look at what was happening''}.
96 41 Migrating to SPB platform also provided an \textbf{easier monitoring and
97 42 increase interactions between development team and public servants by
98 43 coordinators}. As shown by collected data, in the last 15 months of the project,
99   -775 issues and 4,658 issue comments was registered in the main repository
100   -(without considering the software repositories that integrated the platform)
101   -within the SPB platform. The issues have 59 different authors (8 from MPOG
102   -staff), and commented by 64 different users (9 form MPOG staff and users).
  44 +the issues have 59 different authors (8 from MPOG
  45 +staff), and commented by 64 different users (9 from MPOG staff and users).
103 46 Considering issues with higher level of interaction those that have 10 or more
104   -comments, in a set of 84 issues, MPOG staff authored 36 issues (which represents
105   -about 43\% of these most active issues). A MPOG analyst highlighted that
  47 +comments, in a set of 102 issues, MPOG staff authored 43 issues (which represents
  48 +42\% of these most active issues). A MPOG analyst highlighted that
106 49 \textit{``there was a lot of evolution, a lot of communication via Gitlab''}.
107 50 This interaction also led MPOG staff to \textbf{trust developed code}:
108 51 \textit{``Everything was validated, we tested the features and the project was
... ... @@ -220,3 +163,4 @@ for this was that the coaches were more likely to meet the requirements, to
220 163 ask questions about requirements, to understand some features. interaction with
221 164 leaders than with senior developers. Sometimes the coaches brought the question
222 165 to the senior developers''}.
  166 +
... ...
icse2018/content/06-discussion.tex
  Diff comments   View file @7993fa1
... ... @@ -4,15 +4,13 @@
4 4 In this paper we examined the empirical model built in a collaborative project
5 5 between government and academia that successfully harmonized the differences in
6 6 the common approaches to software development management used by each side. We
7   -mapped the key decisions made over the 30-months of the project, that aimed to
8   -improve communication and the development process as a whole. We also elaborated
9   -two surveys and one interviews that were conducted separately for three groups
10   -of participants. We obtained a total of responses of 37 undergraduated
11   -students, eight IT market professionals, and two government officials. Finally,
12   -we collected post-mortem public data on project management carried out on the
13   -platform itself. The results revealed nine practices were developed from three
14   -main decisions taken and 11 benefits were obtained with the adoption of these
15   -practices.
  7 +mapped the key decisions made over the 30-months of the project, that aimed at
  8 +improvement of the communication and the development process as a whole. We also elaborated
  9 +two surveys and one interview that were conducted separately for three groups
  10 +of participants. We obtained a total of 47 respondents: 37 interns, eight IT market professionals, and two government officials. Finally,
  11 +we collected \textit{post-mortem} public data on project management carried out on the
  12 +platform itself. The results revealed that nine practices were developed from three
  13 +key decisions taken, and these practices brought 11 benefits, as summarized in the Table \ref{practices-table}.
16 14  
17 15 \begin{table}[]
18 16 \centering
... ... @@ -66,57 +64,26 @@ bureaucratic issues involve board directors. \item Continuous Delivery
66 64 \label{practices-table}
67 65 \end{table}
68 66  
69   -...summarized in the Table \ref{practices-table} ...
  67 +\textbf{RQ1.}\textit{What practices based on open source development experiences would
  68 +help to combine teams with different management processes in a
  69 +government-academia collaboration project?}
70 70  
71   -\todo{Responder questões de pesquisa}
  71 +We mapped nine practices to reconcile the differences between government and academia in a collaborative project. These practices cover aspects from communication of the project to the delivery process of developed code, as presented in the second column of the table above (Practice Explanation).
72 72  
  73 +\textbf{RQ2.}\textit{How do open source development practices benefit the process of
  74 +developing an e-government platform in a government-academia collaboration?}
73 75  
74   -In our previous work \cite {meirelles2017spb}, we presented the unprecedent
75   -platform developed in the case study project and seven lessons learned taking into account only the
76   -academia-side view. The new results acquired in the current work corroborate
77   -with these lessons, adding the point of view of the government and the academia
78   -in diverse performed levels. In addition, these results suggest that many free
79   -software development practices can be replicated in other contexts in which the
80   -diversity and plurality of its stakeholders need to be leveled and reconciled.
  76 +The results of the surveys revealed the benefits of implementing each set of practices for the case study. The third column of the table (Benefits) shows how the practices adopted impacted on the relationship between members from both sides, on the understanding of project development process, and on the appropriation of the developed platform.
81 77  
82   -% How to involve students real-world projects, interacting with real customers
83   -%The participation of experienced professionals is crucial to succcess of the project}
84   -%A balanced relationship between academia and industry}
85   -%Managing different organizational cultures}
86   -%Manage higher-level and lower-level goals separately}
87   -%Living will ill-advised political decisions}
88   -%Consider sustainability from the beginning}
  78 +The new evidences corroborate with the lessons learned and reported in our previous work \cite{meirelles2017spb}, adding the point of view of the government and the academia in diverse performed levels. Moreover, our results suggest that many open source practices could be replicated in different contexts in which the diversity and plurality of its stakeholders need to be leveled and reconciled.
89 79  
90   -The results obtained also showed questions that were not overcome during the
91   -project and which we believe need to be evaluated for future collaborations
92   -between government and academia for software development:
93   -\begin {itemize}
94   -\item Improving understanding about collaboration: \textit{"During development,
95   -we realized that the development team also felt like the owner of the project,
96   -not just a mere executor. partnership, then it had a lot of that team issue to
97   -suggest things to be put into the project. It was not a customer relationship it
98   -was a partnership relationship, so there was a lot of issue suggesting by the
99   -team to be put into the project"}
100   -\item Discussion of roles and responsibilities: \textit{"Who had the power to
101   -make a decision? There was no one, because it was a very equal relationship. The
102   -two organs were on the same hierarchical level within the work plane. But this
103   -does not work well, you have to leave well defined to whom the last word belongs
104   -in the decisions, because the conflicts will always happen."}.
105   -\item Look for a balance in the requirements definition. The responses showed
106   -that the government felt that it was not detailed enough and the development
107   -team felt that the requirements needed to be matured with the use.
108   -\item Smoothing the intermediations between the different roles \textit{"When we
109   -had the [UnB] coordinator, when we forwarded a direct question to a developer,
110   -the coordinator responded. So that was negative, because we felt a little
111   -coerced from talking directly to the teams"}
112   -\end {itemize}
  80 +This current work also exposed issues that were not overcome during the
  81 +project and need to be evaluated for future government-academia collaborations for software development. In the interviews, MPOG analysts reported some difficulties during the project in understanding the idea of collaboration. They said they needed time to realize that the project was not client-executor relationship, but a partnership, and both organizations were ate the same hierarchical level in the work plane. They lacked the role of decision maker in times of deadlock and in the requirements definition. Additionally, the analysts reported they sometimes felt coerced by coordinators when they tried to communicate directly with the interns.
113 82  
114   -As future work, we intend to reapply in another government-academia paternship
  83 +We consider limitations of this work to be the lack of traceable qualitative and quantitative records related to the first phase of the project (about the organization prior to the adoption of the practices mentioned above) and the application of surveys only after project completion, depending on the good memory of the interviewees about 30 months of the project.
  84 +
  85 +As future work, we intend to apply in another government-academia partnership
115 86 project the practices evidenced from this case study, and conduct
116 87 qualitative and quantitative research throughout its execution. We also intend to
117   -analyze the effectiveness in adopting free software development practices to
  88 +analyze the effectiveness in adopting open source practices to
118 89 align the demands and expectations of a G-A collaboration.
119   -
120   -
121   -
122   -
... ...