Good Practices in Requirements, Project and Risk Management in Educational IT Projects
Total Page:16
File Type:pdf, Size:1020Kb
Proceedings of the Federated Conference on ISBN 978-83-60810-51-4 Computer Science and Information Systems pp. 1017–1021 Good practices in requirements, project and risk management in educational IT projects Małgorzata Alicja Płotka Paweł Syty Faculty of Information Technology, Polish-Japanese Faculty of Applied Physics and Mathematics, Gdańsk Institute of Information Technology, University of Technology, ul. Brzegi 55, 80-045 Gdańsk, Poland ul. Narutowicza 11/12, 80-233 Gdańsk, Poland Email: [email protected] Email: [email protected] main experts. On the other hand, poor or inadequate project Abstract—One can find many learning aids and simulations management contributes to improper organisation of the of physical phenomena on the market – provided as a project team’s work. Then, even if project goals (require- standalone application or as part of an educational package. ments, tasks etc) are defined properly, the achievement of an However, only a few of them allow for the building of interactive experiments: experiments similar to those that objective may be hampered or impossible. should be conducted in physics laboratories at schools. Gdańsk All of these considerations have influenced the project de- University of Technology decided to fill this market niche by signers who are working on the “e-Experiments in physics” designing and constructing a set of virtual experiments – so project (see Section II), to make all reasonable endeavours called e-experiments. To avoid common problems that a lot of to prepare a product that fully satisfies the future users. Sets IT products brought to defeat, they prepared procedures in of activities were planned to achieve this goal. This paper accordance with the best practices of software engineering. The paper below describes the process of the e-experiments describes the software engineering process which they view development paying special attention to requirement, project as resulting in success. and risk management. Authors try to prove that by not The structure of work is as follows. After this short escaping from difficult matters such as carefully planning and introduction, Section II briefly discusses the IT project, risk analysis success can and will be achieved. which is the subject of this work, its aims and products. The third chapter discusses issues related to engineering I. INTRODUCTION requirements. Chapter IV provides a risk analysis, Chapter ANY surveys have been conducted to find out how V describes the project management method. Section VI Mmany IT projects end in defeat and to determine the discusses the current status of the project. The work ends factors which result in their failure. The most commonly with some brief conclusions. indicated reasons for IT project failure are: ineffective stakeholder engagement [1], a complete lack of executive II.THE PROJECT “E-EXPERIMENTS IN PHYSICS” support [1]–[6], ineffective user involvement [1]–[6], and In response to a call for innovative projects in frames of poor project management [1], [7]–[10] (lack of knowledge the European Social Fund, Human Capital Operational Pro- of project management methodologies and the competence gramme, announced by the Polish Ministry of National Edu- of management – inadequately trained and/or inexperienced cation [13], Gdańsk University of Technology proposed, in project managers; lack of top management involvement and cooperation with the Young Digital Planet SA (Gdańsk, support; inadequate risk management and weak project Poland) and L.C.G. Malmberg B.V. (Den Bosch, Nether- plans [11]). Another important reason is a lack of domain lands), project called "e-Experiments in physics," whose knowledge among project team members. main result is a product that addresses some identified prob- A lack of client/end-user commitment usually leads to lems with didactics of physics in secondary schools [14]– ‘challenges’ surrounding requirements that may increase the [17]. The product is a series of virtual experiments (so- risk of not fulfilling clients’ needs. This means that the soft- called e-experiments), carried out in electronic form (as ware does not satisfy the quality conditions specified in the computer programs). Physical phenomena represented by ISO 9001:2000/2008 definition of software quality [12]. the e-experiments were selected in such a way that every Having experience and knowledge deficiencies in the sub- branch of physics is adequately represented. The teachers, ject area of the project may lead to gaps (undefined require- even in well-equipped school physics labs, are not able to ments arising from lack of awareness of the domain of the conduct experiments with some branches of physics (e.g. problem) in software requirement specification or work on nuclear physics) – likewise the inability to demonstrate the unattainable objectives in subsequent project phases. Of behaviour of such a test system in the accelerating elevator, course the software developer is not expected to know ev- train or even on another planet. e-Experiments enable the erything. However, it is necessary to fill in the gaps. For this student freedom to experiment, allowing for a more and cre- purpose it may be helpful to use other sources of informa- ative research activity, thanks to “touch” the problem of per- tion such as documents, standards and the knowledge of do- forming the appropriate exercises using a computer, without The project “e-Experiments in physics” is co-financed by the European the fear of destroying any expensive equipment. Union within the European Social Fund. 978-83-60810-51-4/$25.00 c 2012 IEEE 1017 1018 PROCEEDINGS OF THE FEDCSIS. WROCŁAW, 2012 It should be noted that the e-experiments will not be experiments, based on their best knowledge and experience typical of all simulations that are widely available on the gained during their academic work as well as analysis of the Internet [18]. In contrast, the proposed e-experiments will be current curriculum in force at upper secondary school. as close as possible to reality, will also form part of the Additionally, at the request of the of the originator of the scheme design / build / execute / analyse / introduce the project, nationwide surveys of the teachers and students of results, where it is important to learn from mistakes. The physics in secondary schools were conducted, among other proposed solution involves the possibility of interference in things, to determine the order in which experiments should student performance, thus build e-experiments carried out in be built. The work of the subject matter experts is supported order to force her/ him to an activity and arouse their by a methodologist from one of the best secondary schools scientific curiosity and identification of the research in Poland. problems. We will enable students (and of course the B. Specification of Requirements teacher) to observe the behaviour of the system and its differing parameters, which would be quite impractical The software requirement specification consists of within the physical realm. References to the interdisciplinary scenarios of each e-experiment, description of tools nature of science will be indicated on the e-experiments, for necessary to build the experimental set, and prototypes of example, the results will be analysed using statistical the e-experiments in the form of C++ codes (numerical methods (mathematics) and developed using a spreadsheet engine). A preliminary version of the specification is (computing). Additionally, some e-experiments will be prepared by domain experts of GUT. In the next step the bordering on physical chemistry. Currently, these kind of methodologist reviews the preliminary version of the script references are rather sporadic. The idea described above has and proposes any amendments or modifications. not been previously used in similar solutions. Moreover an Subsequently, the documents drawn up are sent to YDP, to exercise book demonstrating its potential use within its verify the feasibility of the proposed solutions. The genre will be supplied to each e-experiment. scenarios are commented by YDP’s team leaders (at least In the project, Gdańsk University of Technology (further one of them acquired domain knowledge of a project subject referred as GUT) is responsible for the scenarios of the e- – in physics) and sent back to GUT. These two steps are experiments, numerical engine and the exercise books. repeated until any ambiguities are eradicated, and the final Young Digital Planet SA (YDP) is responsible for scenario is accepted by both partners. In the next step, YDP technological tasks: coding, providing graphics and user estimates the time effort (man-hours) needed to implement interface to the application. Role of the third partner, L.C.G. the final scenario, and provides the result to GUT. When a Malmberg B.V. (MBG) is to provide substantial support. scenario contains alternate paths, YDP makes an estimation of each path. In this case, GUT decides what path will be III. REQUIREMENT MANAGEMENT implemented. Then, the developer’s project team at YDP starts implementing the final version of the scenario (using A. Gathering of Requirements the Adobe Air / Alchemy technology). The group of subject matter experts (domain experts) is All of these activities are repeated for each of the 23 e- engaged in work on gathering requirements – academic staff experiments planned to be carried out. and students of the Gdańsk University of Technology. At C. Verification – Do We Build Software Well? the head of