| 1. |
- Rönkkö, Kari, et al.
(författare)
-
Bad Practice or Bad Methods Are Software Engineering and Ethnographic Discourses Incompatible?
- 2002
-
Konferensbidrag (refereegranskat)abstract
- Organizational problems in industry have evoked increased interest in empirical methodologies in the broader software engineering community. In this article ethnography and its relation to software engineering is addressed. Until now sociologists have performed the majority of ethnographic studies on software development. But how useful are these studies for software engineering? Ethnography emphasizes the members' point of view in order to understand the social. Studies from the members' perspective can be interpreted, as revealing 'bad methods' that do not work in complex work situations. From a software engineering point of view, they are just as easy point to the opposite as 'bad practice', bad application of existing methods. The objective of this paper is to promote ethnography and its contribution to software engineering by revealing the different research attitudes of ethnographers and software engineers. Possibilities how to combine ethnographic studies with software method improvement are indicated.
|
|
| 2. |
|
|
| 3. |
- Rönkkö, Kari, et al.
(författare)
-
Personas is not Applicable : Local Remedies Interpreted in a Wider Context
- 2004
-
Konferensbidrag (refereegranskat)abstract
- One of the major problems with participatory design is that it is extremely difficult to apply it to current developments. Software development for the mass market is one aspect of current developments which has been addressed. The problem of how to apply participatory design invariably leads to questioning its relevance to present-day circumstances. It is suggested that new patterns of dominance must be revealed. The usability method known as 'personas' has been demonstrated to remedy the problems of including social and political issues in mass market software developments. This paper demonstrates how the application of personas to a mass market software development project failed because of patterns of dominance in the telecom branch which were unrecognised at the time. The identifying of these patterns of dominance contributes to a better understanding of some of the new patterns of power and domination in mass-market software developments that PD stands before. Copyright 2004 ACM.
|
|
| 4. |
|
|
| 5. |
- Dittrich, Yvonne, et al.
(författare)
-
Co-Operative Method Development revisited
- 2005
-
Konferensbidrag (refereegranskat)abstract
- During the last five years, we applied a research approach we call 'Co-operative Method Development' formulated on first experience with empirical research focusing especially on the social side of software engineering. This position paper summarizes the experiences and discusses the improvement and further development of this research approach based on our experiences in different research projects in co-operation with industrial partners.
|
|
| 6. |
- Dittrich, Yvonne, et al.
(författare)
-
Talking Design : Co-Construction and Use of Representations in Software Development
- 1999
-
Konferensbidrag (refereegranskat)abstract
- Software development differs from other design work insofar as the object to be designed is not visible. Representations play an important role. Even as they only describe aspects of the later software, they mediate the common design work. Software engineering literature focuses on persistent representations, documents, diagrams, mock-ups, or similar things. Our article puts 'talking design', where the software is represented in utterances, sounds, and enactment, in the centre. With the help of concepts from the CSCW discourse, we conceptualise what is happening here; the collaborative object for the design talk is not given, it has to be collectively constructed. Software development can be regarded as routine co-construction. In our case the protocol of that design meeting seemed to serve as a reminder for the participants rather than as in itself representing the design decided upon. The design meeting, we focus in this article, was part of a distributed software development project, with a larger project situated in Ronneby, Sweden and a smaller one in Oulu, Finland. If important parts of design are collectively constructed during such meetings, what does that imply for co-operation, co-ordination and division of labour in software development projects? How can a common practice be developed among distributed work groups?
|
|
| 7. |
|
|
| 8. |
|
|
| 9. |
- Johansson, Conny, et al.
(författare)
-
Commitment as an Underlying Principle for Learning
- 2004
-
Konferensbidrag (refereegranskat)abstract
- The prevailingmodel of software development on which most educational programs are based is in conflict with general practice in industry. As following paper demonstrates Software Engineering education lacks an approach to teach the skills needed to master coalitions of existing recourses that are hard to control. In order to prepare students to handle unpredictable, non-technical and moving targets, an adequate curriculum is needed. Since 1990 software engineering education at Blekinge Institute of Technology has used commitment as the underlying principle for learning. This principle has made it possible to address the discrepancies between education and industry. This paper describes and evaluates our experience of using six elements of commitment in the education of software engineers.
|
|
| 10. |
- Petersen, Kai, et al.
(författare)
-
The impact of time controlled reading on software inspection effectiveness and efficiency : a controlled experiment
- 2008
-
Konferensbidrag (refereegranskat)abstract
- Reading techniques help to guide reviewers during individual software inspections. In this experiment, we completely transfer the principle of statistical usage testing to inspection reading techniques for the first time. Statistical usage testing relies on a usage profile to determine how intensively certain parts of the system shall be tested from the users' perspective. Usage-based reading applies statistical usage testing principles by utilizing prioritized use cases as a driver for inspecting software artifacts (e.g., design). In order to reflect how intensively certain use cases should be inspected, time budgets are introduced to usage-based reading where a maximum inspection time is assigned to each use case. High priority use cases receive more time than low priority use cases. A controlled experiment is conducted with 23 Software Engineering M.Sc. students inspecting a design document. In this experiment, usage-based reading without time budgets is compared with time controlled usage-based reading. The result of the experiment is that time budgets do not significantly improve inspection performance. In conclusion, it is sufficient to only use prioritized use cases to successfully transfer statistical usage testing to inspections.
|
|
