A short description is given of software process models and the issues they address. An outline is given of the process steps involved in the spiral model, an evolving risk-driven approach that provides a framework for guiding the software process, and its application to a software project is shown. A summary is given of the primary advantages and implications involved in using the spiral model and the primary difficulties in using it at its current incomplete level of elaboration. >

A spiral model of software development and enhancement

物件導向軟體之架構(Object-Oriented Software Construction)探討

This book introduces a customer-centered approach to business by showing how data gathered from people while they work can drive the definition of a product or process while supporting the needs of teams and their organizations. This is a practical, hands-on guide for anyone trying to design systems that reflect the way customers want to do their work. The authors developed Contextual Design, the method discussed here, through their work with teams struggling to design products and internal systems. In this book, you'll find the underlying principles of the method and how to apply them to different problems, constraints, and organizational situations.

Contextual Design enables you to
+ gather detailed data about how people work and use systems 
+ develop a coherent picture of a whole customer population 
+ generate systems designs from a knowledge of customer work
+ diagram a set of existing systems, showing their relationships, inconsistencies, redundancies, and omissions

Table of Contents

Chapter 1 Introduction
Chapter 2 Gathering Customer Data
Chapter 3 Principles of Contextual Inquiry
Chapter 4 Contextual Inquiry in Practice
Chapter 5 A Language of Work
Chapter 6 Work Models
Chapter 7 The Interpretation Session
Chapter 8 Consolidation
Chapter 9 Creating One View of the Customer
Chapter 10 Communicating to the Organization
Chapter 11 Work Redesign
Chapter 12 Using Data to Drive Design
Chapter 13 Design from Data
Chapter 14 System Design
Chapter 15 The User Environment Design
Chapter 16 Project Planning and Strategy
Chapter 17 Prototyping as a Design Tool
Chapter 18 From Structure to User Interface
Chapter 19 Iterating with a Prototype
Chapter 20 Putting It into Practice

Contextual Design: Defining Customer-Centered Systems

Essentially a software system's utility is determined by both its functionality and its non-functional characteristics, such as usability, flexibility, performance, interoperability and security. Nonetheless, there has been a lop-sided emphasis in the functionality of the software, even though the functionality is not useful or usable without the necessary non-functional characteristics. In this chapter, we review the state of the art on the treatment of non-functional requirements (hereafter, NFRs), while providing some prospects for future directions.

/pdf/on-non-functional-requirements-in-software-engineering-3a6a23qlo6.pdf

On Non-Functional Requirements in Software Engineering

The Study of Man. By Michael Polanyi. Price, $1.75. Pp. 102. University of Chicago Press, 5750 Ellis Ave., Chicago 37, 1959. One subtitle to Polanyi's challenging and fascinating book might be The Evolution and Natural History of Error , for Polanyi is at pains to expunge what he believes to be the false notion contained in the contemporary view of science which treats it as an object and basically impersonal discipline. According to Polanyi not only is this a radical and important error, but it is harmful to the objectives of science itself. Another subtitle could be Farewell to Detachment , for in place of cold objectivity he develops the idea that science is necessarily intensely personal. It is a human endeavor and human point of view which cannot be divorced from nor uprooted out of the human matrix from which it arises and in which it works. For a good while

Personal Knowledge: Towards a Post-Critical Philosophy

This book is a must-have for all IT professionals facing software development problems on a daily basis. If you are a systems analyst or requirements engineer it will provide an essential, practical guide from the task of identifying the problem to making the descriptions needed to resolve it.

Problem Frames: Analyzing and Structuring Software Development Problems

Research in requirements engineering has produced an extensive body of knowledge, but there are four areas in which the foundation of the discipline seems weak or obscure. This article shines some light in the “four dark corners,” exposing problems and proposing solutions. We show that all descriptions involved in requirements engineering should be descriptions of the environment. We show that certain control information is necessary for sound requirements engineering, and we explain the close association between domain knowledge and refinement of requirements. Together these conclusions explain the precise nature of requirements, specifications, and domain knowledge, as well as the precise nature of the relationships among them. They establish minimum standards for what information should be represented in a requirements language. They also make it possible to determine exactly what it means for requirements and engineering to be successfully completed.

/pdf/four-dark-corners-of-requirements-engineering-3tofy7azs9.pdf

Four dark corners of requirements engineering

The original program design text. This book is about programming for data processing applications, and its purpose is to present a coherent method and procedure for designing systems, programs, and components that are transparently simple and self-evidently correct. The main emphasis is on the structure: on the dissection of a problem into parts and the arrangement of those parts to form a solution.

Principles of program design

Foreword by Jon Bentley. Preface. Acknowledgements. Introduction. A. Ambiguity. The Application Domain. Arboricide. Aspects of Software Development. B. The Bridges of Konigsberg. Brilliance. C. The Calendar. Classification. Composition. Connection Domains. Connection Frames. Context Diagrams. Critical Reading. D. Dataflow Diagrams--1. Dataflow Diagrams--2. Definitions. Dekker. Descriptions. Designations. Deskilling. Domain Characteristics. Domain Interactions. Domains. E. Entity-Relation Span. Events and Intervals. Existence. F. Frame Diagrams. The Fudge Factor. G. Graphic Notations. H. Hierarchical Structure. I. Identity. Implementation Bias. Individuals. Informal Domains. Is. J. JSP Frame. L. Logical Positivism. M. Machines. Mathematics. Method. Misfits. Models. Mood. A Multi-Frame Problem--1. A Multi-Frame Problem--2. N. The Narrow Bridge. O. Object-Oriented Analysis. P. The Package Router Problem. Partial Descriptions. Phenomena. Poetry. Polya. Predicate Logic. Problem Complexity. The Problem Context. Problem Frames. Problem Sensitivity. Procrustes. R. Raw Materials. Refutable Descriptions. Reification. Requirements. Restaurants. Rough Sketches. S. Scope of Description. Shared Phenomena. Simple Control Frame. Simple IS Frame. Software. Software Engineering. Span of Description. Specifications. T. Top-Down. Tree Diagrams. Trip-lets. W. What and How. Bibliography. Index.

Software requirements & specifications: a lexicon of practice, principles and prejudices

Distributed Feature Composition (DFC) is a new technology for feature specification and composition, based on a virtual architecture offering benefits analogous to those of a pipe-and-filter architecture. In the DFC architecture, customer calls are processed by dynamically assembled configurations of filter-like components: each component implements an applicable feature, and communicates with its neighbors by featureless internal calls that are connected by the underlying architectural substrate.

/pdf/distributed-feature-composition-a-virtual-architecture-for-1lmb1n2lhz.pdf

Michael Jackson

Papers

Problem Frames: Analyzing and Structuring Software Development Problems

Four dark corners of requirements engineering

Principles of program design

Software requirements & specifications: a lexicon of practice, principles and prejudices

Distributed feature composition: a virtual architecture for telecommunications services