Cargando…

Rationale Management in Software Engineering

Thirty years ago, I first entered the dark realm of software engineering, through a prior interest in documentation. In those days, documentation pretty much meant functional specifications. The idea that stakeholders in a system (its implementers, its end-users, its maintainers, and so forth) might...

Descripción completa

Detalles Bibliográficos
Clasificación:Libro Electrónico
Autor Corporativo: SpringerLink (Online service)
Otros Autores: Dutoit, Allen H. (Editor ), McCall, Raymond (Editor ), Mistrik, Ivan (Editor ), Paech, Barbara (Editor )
Formato: Electrónico eBook
Idioma:Inglés
Publicado: Berlin, Heidelberg : Springer Berlin Heidelberg : Imprint: Springer, 2006.
Edición:1st ed. 2006.
Temas:
Acceso en línea:Texto Completo

MARC

LEADER 00000nam a22000005i 4500
001 978-3-540-30998-7
003 DE-He213
005 20220119211437.0
007 cr nn 008mamaa
008 100301s2006 gw | s |||| 0|eng d
020 |a 9783540309987  |9 978-3-540-30998-7 
024 7 |a 10.1007/978-3-540-30998-7  |2 doi 
050 4 |a QA76.758 
072 7 |a UMZ  |2 bicssc 
072 7 |a COM051230  |2 bisacsh 
072 7 |a UMZ  |2 thema 
082 0 4 |a 005.1  |2 23 
245 1 0 |a Rationale Management in Software Engineering  |h [electronic resource] /  |c edited by Allen H. Dutoit, Raymond McCall, Ivan Mistrik, Barbara Paech. 
250 |a 1st ed. 2006. 
264 1 |a Berlin, Heidelberg :  |b Springer Berlin Heidelberg :  |b Imprint: Springer,  |c 2006. 
300 |a XXII, 434 p.  |b online resource. 
336 |a text  |b txt  |2 rdacontent 
337 |a computer  |b c  |2 rdamedia 
338 |a online resource  |b cr  |2 rdacarrier 
347 |a text file  |b PDF  |2 rda 
505 0 |a Fundamentals - Rationale Representation, Capture, and Use -- Rationale Management in Software Engineering: Concepts and Techniques -- Three Studies of Design Rationale as Explanation -- Effective Design Rationale: Understanding the Barriers -- Rationale as a By-Product -- Hypermedia Support for Argumentation-Based Rationale -- Rationale Management for Requirements Engineering -- A Hybrid Approach to Upstream Requirements: IBIS and Cognitive Mapping -- From DREAM to Reality: Specificities of Interactive Systems Development With Respect To Rationale Management -- The WinWin Approach: Using a Requirements Negotiation Tool for Rationale Capture and Use -- Design Rationale in Exemplary Business Process Modeling -- Promoting and Supporting Requirements Engineering Creativity -- Design Rationale and Software Architecting -- A Framework for Supporting Architecture Knowledge and Rationale Management -- Capturing and Using Rationale for a Software Architecture -- Rationale-Based Support for Software Maintenance -- The Role of Rationale in the Design of Product Line Architectures - A Case Study from Industry -- The Role and Impact of Assumptions in Software Engineering and its Products -- Design Decisions: The Bridge between Rationale and Architecture -- Rationale for Organizing Bodies of Knowledge -- Reusable Rationale Blocks: Improving Quality and Efficiency of Design Choices -- Defining Agile Patterns -- Capturing and Reusing Rationale Associated with Requirements Engineering Process Improvement: A Case Study -- Using Patterns for Sharing Requirements Engineering Process Rationales. 
520 |a Thirty years ago, I first entered the dark realm of software engineering, through a prior interest in documentation. In those days, documentation pretty much meant functional specifications. The idea that stakeholders in a system (its implementers, its end-users, its maintainers, and so forth) might want something other than an alphabetic list of function definitions was just taking hold. There was an exciting (to me) vision of stakeholders accessing and contributing to explanations of how and why aspects of a system work as they do, tradeoff analysis of concomitant downsides, and perhaps even accounts of why other possible approaches were not followed. There were many challenges to overcome in achieving this vision. The most formidable is the belief that people do not like to create or use do- mentation. This negative image of documentation is (unfortunately) more than just the bias of a few incorrigible system developers. It is more like a deep truth about human information behavior, about how human beings construe and act towards information. Humans are, by default, active users of information; they want to try things out, and get things done. When documentation is interposed as a prerequisite between people and a desired activity, they try to skip through it, circumvent it, or undermine it. Desi- ing information to suit the needs and interests of its users is an abiding challenge, but we have come a long way from functional specifications as the only answer. 
650 0 |a Software engineering. 
650 0 |a Electronic data processing-Management. 
650 0 |a Computer science. 
650 1 4 |a Software Engineering. 
650 2 4 |a IT Operations. 
650 2 4 |a Models of Computation. 
700 1 |a Dutoit, Allen H.  |e editor.  |4 edt  |4 http://id.loc.gov/vocabulary/relators/edt 
700 1 |a McCall, Raymond.  |e editor.  |4 edt  |4 http://id.loc.gov/vocabulary/relators/edt 
700 1 |a Mistrik, Ivan.  |e editor.  |4 edt  |4 http://id.loc.gov/vocabulary/relators/edt 
700 1 |a Paech, Barbara.  |e editor.  |4 edt  |4 http://id.loc.gov/vocabulary/relators/edt 
710 2 |a SpringerLink (Online service) 
773 0 |t Springer Nature eBook 
776 0 8 |i Printed edition:  |z 9783642068164 
776 0 8 |i Printed edition:  |z 9783540819141 
776 0 8 |i Printed edition:  |z 9783540309970 
856 4 0 |u https://doi.uam.elogim.com/10.1007/978-3-540-30998-7  |z Texto Completo 
912 |a ZDB-2-SCS 
912 |a ZDB-2-SXCS 
950 |a Computer Science (SpringerNature-11645) 
950 |a Computer Science (R0) (SpringerNature-43710)