A look at software engineering risks in a team project course

Abstract

Risk identification, management, and

Software engineering problems and their relationship to perceived learning and customer satisfaction on a software capstone project

“…Furthermore, inexperience with the implementation technologies under technology skills and paid work overriding the course project under maintaining motivation were also among the most extensively encountered problems. Similar problems were reported also in previous studies ( Pournaghshband, 1990;Ahtee and Poranen, 2009;Koolmanojwong and Boehm, 2013 ) but any detailed comparison among the studies is impossible due to the different problem classifications used in the studies.…”

“…All but one of the most common serious problems were related to teamwork and social issues, and the remaining one was related to testing. Ahtee and Poranen (2009) list the frequencies of realized risks, and Koolmanojwong and Boehm (2013) the frequencies of identified risks in their capstone projects. Risks can be considered as problems for a project at least if they realize.…”

Students' Perceptions of Software Risks

“…Our contributions lie in the analysis of students' own perceptions of risks and their use of risks in managing the agile software development. The risks perceived by our students differed from those reported in prior studies 9,10,11,12 . Furthermore, our classification of the results of the first offering of the course suggested collaborative ways of identifying and mitigating the risks.…”

“…Common techniques introduced in undergraduate software engineering courses include risk exposure, which quantitatively analyzes the probability of an unsatisfactory outcome and the loss to the stakeholders affected if the outcome is unsatisfactory 9 . Another method taught in the classroom, as well as used in industry, is the listing of project top-n risk items (e.g., n=10) 9,10,11,12 . Examples of top ranked risk items are personnel shortfalls, requirements volatility, architecture complexity, and quality tradeoffs.…”

“…Koolmanojwong and Boehm 12 analyzed the risks encountered by student teams in a graduatelevel software engineering course sequence (i.e., two semesters of fall and spring). The students were grouped in a 5-or 6-people project team and their grades were used to correlate their risk management activities.…”