All the Articles are related to the Management And Softwares.
Another case study [29] documented Compendium’s use in a time-pressured initiative to conduct an enterprise-wide risk assessment for a Year 2000 Contingency Plan. In this project, as in many others, one of the most common purposes of meetings was to advance a project deliverable of some sort, in this case to generate organizational documents. Figure …
When one of the above types of prototypes is selected, a certain kind of information and rationale is sought. During prototype development, further rationale is created (why to do it that way?). During development, the flow state [5] may be reached, and an interruption will hamper the creation process. However, as soon as the prototype …
Few would disagree with this book’s opening chapter that the systematic management of design rationale (DR) is not yet common software engineering practice. By extension this applies to the particular flavor of DR with which we work, namely the IBIS/QOC approaches to creating graphical argumentation maps of design deliberation (reviewed in Chap. 1 and classed …
Hypermedia Support for Argumentation-Based Rationale: 15 Years on from ibis and QOC. Read More »
Additional paths and structures are captured while audio or video sources are recorded. For example, simple recordings can be replayed. In the end, there are several different recordings from one recorded session, e.g. a sequence of DOORS requirements discussed (sequence of Req.-IDs), specification structure (requirements within table of contents), and audio recording of discussion (time-indexed …
FOCUS is a strategy and a family of tools to capture knowledge sparked by prototypes [16]. According to Lichter et al. [12], there are different kinds of prototypes that are built with different goals in mind. The definitions of various types of prototypes are listed below, with respective rationale mentioned in parentheses. −Demonstrators elicit requirements …
This principle differentiates the approach from simple recording. While audio or video recording would not necessarily require a computer, this principle demands the recordings to be computerized (at least in the end). But there is more to this principle: the more one knows about the focus task at hand, the more additional information can be …
Compendium extends the use of IBIS from modeling a discussion, to more systematic modeling of a problem. A modeling approach focuses attention on a specific subset of issues and information, it may constrain the kinds of options one considers, and it may also focus attention on how one assesses them. In Compendium, a modeling approach …
Rationale is among the most importantt information a software project produces. It is important to know why a decision has been made and why one design or solution has been preferred over another. Later decisions are facilitated by knowing why earlier decisions have been made. During maintenance, documented rationale can save a large percentage of …
Visions, requirements, and reasons for them first appear in the earliest project phase. Communication in this phase is typically based on informal meetings, slide presentations, and oral discussions. After a while, more formal requirements engineering takes over. Design decisions are mainly discussed by technical experts and architects during the design phase. Decisions are made by …
Since rationale is so essential for project success, one would expect it to be highly regarded and captured carefully. However, that is seldom the case, as Chap. 1 states in some detail and with reference to the literature. Due to its perplexing nature, I call this observation the “Rationale Paradox”: The Rationale Paradox: When most …
