11.4.1 From Waterfall to Evolutionary Development (Evo): How we rapidly created faster, more user‐friendly, and more productive software products for a competitive multi‐national market

Johansen, Trond Cato; Gilb, Tom

doi:10.1002/j.2334-5837.2005.tb00781.x

Cited by 13 publications

(14 citation statements)

References 2 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Step-> Table 1: This is a conceptual example, but is very close to actual practice by our clients (Johansen 2005). Three goals (performance targets) and two resource targets are having the real impacts on them tracked, as steps are delivered.…”

Section: Planguage Methods Supporting Priority Determinationmentioning

confidence: 89%

11.4.2 Managing Priorities: A Key to Systematic Decision‐Making

Gilb¹,

Maier²

2005

INCOSE International Symp

Self Cite

View full text Add to dashboard Cite

Abstract.A central concern of systems engineering is selecting the most preferred alternatives for implementation from among competing options. The selection process is sometimes called tradeoff analysis, and is often built on the methods of decision analysis and utility theory. The process can be loosely divided into two parts, a first part in which one determines the relative priority of various requirements, and a second part, a design selection phase, in which alternatives are compared, and the preferred alternatives chosen. This paper discusses the means of determining the priority order for implementing system changes. It also outlines the implications on the selection process of evolutionary systems development.

show abstract

Section: Planguage Methods Supporting Priority Determinationmentioning

confidence: 89%

11.4.2 Managing Priorities: A Key to Systematic Decision‐Making

Gilb¹,

Maier²

2005

INCOSE International Symp

Self Cite

View full text Add to dashboard Cite

show abstract

“…The incremental evolutionary model is popular model for application type of software product [31]. It is also suited for the application software product development where the requirements are complex and are rapidly changing [9,25,14,17,28,23].…”

Section: Table 1 Some Sample Production-rulesmentioning

confidence: 99%

A rule-based recommendation system for selection of software development life cycle models

Kumar

2013

SIGSOFT Softw. Eng. Notes

View full text Add to dashboard Cite

The selection of a software development life cycle (SDLC) model for a software project is highly dependent upon the characteristics of the software product to be developed. We classified software products according to characteristics that matter for SDLC selection. We surveyed literature to elicit recommendations for SDLC selection. We formalized our findings to present a rule based recommendation system that can be helpful to software developers in selecting the most appropriate SDLC model to be used for the development of a software product. We conducted an initial evaluation of our system. We believe our SDLC recommendation system provides useful hints for selecting an SDLC, and provides a base for validating and refining SDLC recommendation rules.

show abstract

“…In contrast, here's an example, the Confirmit case study (Johansen and Gilb 2005), where the focus of the project was not on functionality, but on driving up the system quality. By focusing on the "Usability" and "Performance" quality requirements the project achieved a great deal!…”

Section: Figure 4 Example Of Initial Weak Top Level Critical Objectivesmentioning

confidence: 99%

“…Everybody talks about requirements, but few people seem to be making progress to enhance the quality of their requirements specifications and improve support for software engineering. Yes, there are internationally competitive businesses, like HP and Intel that have long since improved their practices because of their competitive nature and necessity (Johansen and Gilb 2005;Gilb 2012). But they are very different from the majority of organizations building software.…”

Section: Who or What Will Change Things?mentioning

confidence: 99%

7.4.2 What's fundamentally wrong? Improving our approach towards capturing value in requirements specification

Gilb¹,

Brodie²

2012

INCOSE International Symp

Self Cite

View full text Add to dashboard Cite

We are all aware that many of our IT projects fail and disappoint: the poor state of requirements practice is frequently stated as a contributing factor. This article proposes a fundamental cause is that we think like programmers, not engineers and managers. We fail to concentrate on value delivery, and instead focus on functions, on use‐cases and on code delivery. Our requirements specification practices fail to adequately address capturing value‐related information. Compounding this problem, senior management is not taking its responsibility to make things better: managers are not effectively communicating about value and demanding value delivery. This article outlines some practical suggestions aimed at tackling these problems and improving the quality of requirements specification.

show abstract

11.4.1 From Waterfall to Evolutionary Development (Evo): How we rapidly created faster, more user‐friendly, and more productive software products for a competitive multi‐national market

Cited by 13 publications

References 2 publications

11.4.2 Managing Priorities: A Key to Systematic Decision‐Making

11.4.2 Managing Priorities: A Key to Systematic Decision‐Making

A rule-based recommendation system for selection of software development life cycle models

7.4.2 What's fundamentally wrong? Improving our approach towards capturing value in requirements specification

Contact Info

Product

Resources

About