Bibliography
Readings/Notes
The Reach of Software
Engineering
r030300>
0.1.0
2023-10-23 16:30
|
|
Bibliography
Readings/Notes |
|
Software includes computer programs and what is needed to use them [SE: 1.1.1]
Software engineering is seen as an engineering discipline concerned with all aspects of software production [SE: 1.1.2] starting from (software) system specification through maintenance of the (software) system after it has gone into use.
This distinction does not provide much about the system of which the software (system) occurs in an instrumental way. Even in the discussion of (computer-based) system engineering, the focus is inward and artifact centric in tone [SE: 1.1.4].
The reach is further confirmed by placing software specification as the initial stage of the software process [SE: 1.1.5]. It is important that software evolution is included, beyond the validation of the software product against customer requirements. The requirements confirmation process is not itself identified as the leading activity.
The software process model is peculiar in that sometimes the notions here apply to the model inside which the delivered software functions, and sometimes the notions are about the activity of software engineering and development [SE: 1.1.6]. It is clear from the section that it is the software delivery process that is being considered, and not the functions of the software itself, but it is startling to not have that be so clear in terms of the kinds of models.
The limitation of scope is confirmed in regard to the characterization of software engineering methods [SE: 1.1.8]. However, the process of moving up to situation in models, via approaches such as Model Driven Architecture (MDA) are still possible in this view. However, MDA may be confined mostly to software engineering, and hence inward-looking still.
The attributes of good software are about non-functional metrics with regard to the behaving software [SE: 1.1.10]. Usability, and some performance attributes, are the closest that seem to be related to suitability to the task. The prospect for metrics is not introduced at this point.
It is interesting to me that the key challenges would seem to require both abstraction and situation of the software, its integration, and its life cycle [SE: 1.1.11].
The ACM/IEEE Code of Ethics for software engineers is cited, as is the Fred Brooks "No Silver Bulllet paper. [Brooks1995]
Now we look more closely at the scope of system-engineering around computers.
We want to look for broader system-engineering issues that affect software engineering [SE: 2, objectives]. We also want to look at what is meant by the system's environment.
"System engineering is the activity of specifying, designing, implementing, validating, deploying and maintaining systems as a whole. System engineers are [concerned with] software, hardware and the system interactions with users and its environment. They must think about the services that the system provides, the constraints under which the system must be built and operated and the interactions of the system with its environment." [SE: p.21]
The following definition is telling:
"A system is a purposeful collection of interrelated components that work together to achieve some objective." [SE: p.21]
There is emphasis on emergent properties [Checkland1981], ones that cannot be attributed to any specific part of the system, emerging only when the system as a whole is considered. Examples include physical weight, reliability, and usability. There is reference to [White1993] as the source of ideas about CBSE (Computer-Based Software Engineering)and also some observations about the growth in space-program software systems.
The examples are great:
- Functional properties - like bicycle having the functional property of being a transportation device once it has been assembled from its components (but notice the missing reference to the rider).
- Non-functional properties such as reliability, performance, safety and security. (Also noteworthy if we consider the bicycle with and without the rider.)
- For reliability, operator behavior is considered. "Operator error is more likely in conditions of stress." [p.23]. Also it is noted that observed reliability depends on the context in which the system is used.
- Environmentally-related failures and hazards are useful. There is an example of a subsystem that must be operated within a particular range of temperatures, and that failure of an adjacent air-conditioning unit could cause it to be overheated out of proximity to the malfunctioning AC!
- Safety and security pose different problems, it is claimed. Here the problem is the prediction of the absence of something.
- Considers interactions with and from the physical environment that are intended as part of the functioning and that are unintended.
- Looks at organizational environment as well as physical environment. "If the organizational environment is not properly understood, systems may not meet business needs and may be rejected by users and organizational managers." [SE: 2.2 p.25].
- Looks at impact on people including changes of processes and training requirements, deskilling or otherwise changing how people work, and organizational impact. Refers to [Mumford1989], [Checkland1981], [Checkland1990], and [Ackroyd1992].
- Asserts that it is impossible to anticipate all of the environmental factors.
 |
You are navigating Orcmid on GitHub |
created 2003-03-15-21:37Z by orcmid |