Scope of Software Engineering

Five Aspects of Software Engineering:
 

1. Historical Aspects:
1967 - Term software engineering coined by a NATO study group
1997 - 50th anniversary of ACM (Association for Computing Machinery)
1968 - NATO Software Engineering Conference held in Garmisch, Germany
name reflected the belief that software production should be an engineering like activity
Software engineering should use the philosophies and paradigms of established engineering disciplines to solve the software crisis.
Components of Software Engineering:
computer science and math
management
psychology
economics
Differences between developing software and other types of engineering products:
A major fault in a bridge would cause collapse, and the bridge would need to be redesigned and rebuilt
If an operating system crashes, it is usually considered minor, and the solution is simple - just reboot it.
Expectations -- fault tolerance:
bridge should be perfectly engineered - all possible conditions are handled during the design.
software is expected to be imperfect
Engineering uses continuous math and calculus; An operating system is based on discrete math and goes through various states Maintenance:
maintenance of a bridge is restricted to minor repair
It is not unusual for 50% of the source code of an operating system to be rewritten over a 5 year period.
2. Economic Aspects:
 
Relationship between software engineering and computer science:
Computer scientist investigates a variety of ways to produce software, some good and some bad.
Software engineer is interested in only those techniques that make sound economic sense.
some considerations in introducing a new coding technique at an organization:
Since new technique would result in faster coding time, it should be better, but:
cost of introducing new technology into an organization
maintenance consequence
use of the technique may result in code that is difficult to maintain, making the cost higher over the life of the product.
Unfortunately, the aim of both the client and the software provider is often to produce code as quickly as possible.
 
 
 
 
  3. Maintenance Aspects:
 
Life Cycle - series of steps that software undergoes, from concept exploration through final retirement.
Phases of the software life cycle: (general phases)
Requirements phase
concept exploration; client's requirements are elicited
Specification (Analysis) phase
requirements analyzed and put into the specification document; what the product is supposed to do; results in a SPMP - software project management plan
Design phase
 how it is to be done
architectural design (modules)
detailed design (design of the modules)
Implementation phase
Coding and Testing
Integration phase
Components are combined and tested as a whole until developers are satisfied with it.
Then, acceptance testing is done by the client.
Phase ends when:
product is accepted
product goes into operations mode
Maintenance phase
all changes to the product once it meets the specification document.
Includes:
Corrective maintenance (software repair) - no changes to specifications
removal of residual faults
Enhancement (2 types) - changes to specifications are made
Perfective maintenance (such as additional functionality or decreased response time.
Adaptive maintenance (such as in response to changes in government regulations)
Bad products are thrown away; good products are repaired and enhanced. Retirement
Product is removed from service
Maintenance accounts for about 67% of the relative cost of the phases of the software life cycle.
Coding only accounts for 5%
The real world changes, so software must change as a reflection of the real world.
Example: a change in the sales tax rate.
Maintenance in the form of enhancement is a positive part of a company's activities. Because maintenance is so important, a major aspect of software engineering consists of those techniques, tools, and practices that lead to a reduction in maintenance costs. Reducing maintenance costs by 10% will reduce overall costs by nearly 7%.
 

4. Specification and Design Aspects:
 
The earlier a fault is corrected, the better.
The reason that the cost of correcting a fault increases so steeply is related to what has to be done to correct a fault.
Example shown in text: fault costing $40 to detect and correct in design phase would cost about  $2000 to detect and correct in the maintenance phase.
Solution to problem:
employ techniques for detecting faults during the requirements and specification stages.
Between 60 and 70% of all faults are specification and design faults.
Reducing specification and design faults by 10%  will reduce the overall number of faults by 6 to 7%. Software engineering strives to produce techniques that yield better specifications and designs.
 
 
 
 
 
 
 
 
 
 
 
 

5. Team Programming Aspects:
 
Decrease in the performance-price factor has made hardware more affordable, and companies need larger software products than one person can develop and maintain within time constraints.
decrease in the performance-price factor due to discoveries in electronics, particularly the transistor and  VLSI
VLSI = very large scale integration
performance-price factor = time to perform one million additions X cost of CPU and main memory.
Need for software development by teams
Problems with team programming:
interface problems among code components
communications among team members
teams must be organized, or time is wasted in conferences between team members

 
 
 
 
  The Object-Oriented Paradigm:
.History of techniques used:
Before 1975, no specific programming technique was used.
1975 to 1985: development of structured paradigm:
Structured paradigm includes the following techniques:
structured systems analysis
composite/structured design
structured programming
structured testing
Reasons for lack of success:
inability to cope with increasing size of software products
maintenance phase
did not support reuse as well as object-oriented
techniques are either action oriented or data oriented but not both
DFA (Data Flow Analysis) is action oriented
Jackson system development is data oriented
Object-Oriented paradigm considers both data and actions to be of equal importance.
An object is a unified software component that incorporates both the data and the actions that operate on that data.
Information Hiding: Details as to how the data element is stored are not known form outside the object.
The payoff of the implementation details comes during maintenance; changes need only be made within the object itself.
Object-oriented paradigm makes development easier.
there is a close correspondence between the objects in a product and their counterparts in the real world.
Well designed objects are independent units.
conceptual independence is sometimes called encapsulation.
The only allowable form of communication is the sending of a message to the object to carry out a specific action. Comparison:
use of structured paradigm produces a single unit
O.O. paradigm - product consists of a number of smaller, largely independent units; reduces the level of complexity.
O.O. Paradigm promotes reuse.
reuse of objects reduces time and cost of development and maintenance
Phases of the software life cycle using the Object Oriented Paradigm:
Requirements phase
Object-oriented analysis phase
Object-oriented design phase
Object-oriented programming phase
Integration phase
Maintenance phase
Retirement
One of the steps of the Object-oriented analysis phase is to determine the objects.
Architectural design, because the objects are kinds of modules, is accomplished in this phase rather than in the actual design phase.
Terminology used in the text Classical and Object-Oriented Software Engineering:
Software - consists not just of code in machine readable form, but also all the documentation that is an intrinsic component of every project.
Product - used to denote a nontrivial piece of software.
to obviate the program vs system confusion
Book deals with the process of software production and the end result of a process is termed a product.
Software production consists of two phases: software development followed by maintenance. The term system is used in its modern sense, the combined hardware and software. Methodology and paradigm are both used to mean a collection of techniques for carrying out the complete life cycle. One term that is avoided as far as possible is bug.
Error is used instead, because referring to an error as a bug is a way of casting off responsibility.
Grace Hopper (one of the developers of COBOL) - first to use the term applied to software - (a real bug had gotten into the system)
Because there are many different terms used in object-oriented literature, the author chose to use the terms:
attribute for a data component of an object
method with regard to the actions of an object
sending a message denotes when a method within an object is invoked.