1. Chap 4 Software Processes

2. Objectives To introduce software process models
To describe three generic process models and when they may be used
To describe outline process models for requirements engineering, software development, testing and evolution
To explain the Rational Unified Process model
To introduce CASE technology to support software process activities

3. Topics covered 4.1 Software process models 4.2 Process iteration
4.3 Process activities
4.4 The Rational Unified Process
4.5 Computer-aided software engineering

4. What is the software process?
A software process is a set of activities that leads to the production of a software product. These activities may involve the development of software from scratch in a standard programming language. Increasingly, however, new software is developed by extending and modifying existing systems and by configuring and integrating off-the-shelf software or system components.

5. The fundamental activities of software processes.
Although there are many software processes, some fundamental activities are common to all software processes:
Software specification : the functionality of the software and constraints on its operation must be defined.
Software design and implementation : the software to meet the specification must be produced.
Software validation : the software must be validated to ensure that it does what the customer wants.
Software evolution : the software must evolve to meet changing customer needs. 64

6. 4.1 The software process
A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective, and thus provides only partial information about that process.

7. Generic software process models
The waterfall model
Separate and distinct phases of specification development, validation and evolution and represents them as separate process phases such as requirements specification, software design, implementation, testing and so on.
Evolutionary development
This approach interleaves (interchange) the activities of specification, development and validation. An initial system is rapidly developed from abstract specifications. This is then refined with customer input to produce a system that satisfies the customer’s needs.
Component-based software engineering
The system is assembled from existing components, the focuses on integrating these components into a system rather than developing them from scratch.

8. These generic process models are widely used in current software engineering practice. They are not mutually (interchange) exclusive and are often used together, especially for large systems development.
Sub-system within a larger system may be developed using different approaches, but we should understand that, in practice, they are often combined.

9. 4.1.1 Waterfall model
Figure 4.1 the software life cycle

10. 4.1.1 Waterfall model phases
Requirements analysis and definition
The system’s services, constraints and goals are established by consultation with system users. They are then defined a detail system specification.
System and software design
Systems design process partitions the requirements to either hardware or software systems. It establishes an overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships.
Implementation and unit testing
Software design is realized (accomplish) as a set of programs or program units. Unit testing involves verifying that each unit meets its specification.

11. Waterfall model phases
Integration and system testing
Individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met. After testing, the software system is delivered to the Customer.
Operation and maintenance
This is longest life-cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors which were not discovered in earlier stages of the life cycle, improving the implementation of system units and enhancing the system’s services as new requirements are discovered. 67

12. Waterfall model problems
Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.
Therefore, this model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.
Few business systems have stable requirements.
The waterfall model is mostly used for large systems engineering projects where a system is developed at several sites.

13. 4.1.2 Evolutionary development
There are two fundamental types of evolutionary development:
Exploratory development
Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements and add new features as proposed by the customer.
Throw-away prototyping
Objective is to understand the system requirements. Should start with poorly understood requirements to clarify what is really needed.

14. 4.1.2 Evolutionary development
Figure 4.2 Evolutionary development

15. 4.1.2
An evolutionary approach to software development is often more effective than the waterfall approach in producing system that meet the immediate needs of customers.
From an engineering and management perspective, the evolutionary approach has two problems:
Process is not visible: Managers need regular deliverables (report) to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system.
Systems are often poorly structured: Continual change tend to corrupt the software structure. incorporating (combine) software changes becomes increasingly difficult and costly.

16. 4.1.2 Evolutionary development
Problems
Lack of process visibility;
Systems are often poorly structured;
Special skills may be required.
Applicability (suitable)
For small or medium-size interactive systems;
For parts of large systems (e.g. the user interface);
For short-lifetime systems.

17. For small and medium-sized systems (up to 500,000 lines of code)
For small and medium-sized systems (up to 500,000 lines of code). I think that the evolutionary approach is the best approach to development.
For large, complex, long-life-time systems, where different teams develop different part of the system, it is difficult to establish a stable system architecture using this approach. Which makes it hard to integrate contributions from the teams.

18. For large systems, I recommend a mixed process that incorporates the best features of the waterfall and the evolutionary development models.
This may involve developing a throwaway prototype to resolve uncertainties in the system specification, then re-implement the system using a more structured approach.
Part of the system that are well understood can be specified and developed using a waterfall-based process.
Other part of system, such as the user interface, which are difficult to specify in advance, should always be developed using an exploratory programming approach.

19. 4.1.3 Component-based software engineering (CBSE)
Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems.
This approach is becoming increasingly used as component standards have emerged.

20. 4.1.3 Process stages Component analysis; Requirements modification;
Given the requirements specification, a search is made for components to implement that specification. Usually, there is no exact match, and the components that may be used only provide some of the functionality required.
Requirements modification;
During this stage, the requirements are analysed using information about the components that have been discovered. They are then modified to reflect (consider) the available components. Where modifications are impossible, the component analysis activity may be re-entered to search for alternative solutions.

21. System design with reuse;
During this phase, the framework of the system is designed or an existing framework is reused. The designers take into account the components that are reused and organize the framework to cater (supply) to this. Some new software may have to be designed if reusable components are not available.
Development and integration.
Software that cannot be externally procured is developed, and the components and COTS systems are integrated to create the new system. System integration, in this model, may be part of the development process rather than a separate activity.

22. Reuse-oriented development
Figure 4.3 component-based software engineering
CBSE : Component-based software engineering

23. Advantage and short-point of Component-based software engineering
Has obvious advantage of reducing the amount of software to be developed and so reducing cost and risks.
Leads to faster delivery of the software.
However, requirements compromises are inevitable and this may lead to a system that does not meet the real needs of users.
Furthermore, some control over the system evolution is lost as new versions of the reusable components are not under the control of the organization using them.70

24. 4.2 Process iteration
Change is inevitable in all large software projects.
The system requirements change as the business procuring the system responds to external pressures.
Management priorities change.
As new technologies become available designs and implementation change.
This means that the software process is not a one-off process; rather, the process activities are regularly repeated as the system is reworked in response to change requests.

25. 4.2 Two (related) approaches Incremental delivery: Spiral development:
The software specification, design and implementation are broken down into a series of increments that are each developed in turn.
Spiral development:
The development of the system spirals outwards from an initial outline through to the final developed system.

26. 4.2
The essence of iterative processes is that the specification is developed in the same time with the software developed.
However, this conflicts with the procurement model of many organizations where the complete system specification is part of the system development contract.
In the incremental approach, there is no complete system specification until the final increment is specified.
So which large customers such as government agencies may find difficult to accommodate.

27. 4.2.1 Incremental delivery
The waterfall model of development requires customers for a system to commit (make sure) to a set of requirements before design begins and the designer to commit to particular design strategies before implementation.
An evolutionary approach to development allows requirements and design decisions to be delayed but also leads to software that may be poorly structured and difficult to understand and maintain.
Incremental delivery is an in-between approach that combines the advantages of these models. 71

28. In the incremental development process
Customer identify, in outline, the services should be provided in the system.
They identify which of the services are most important and which are least important to them.
A number of delivery increments are then defined, with each increment providing a sub-set of the system functionality.
The allocation (assign) of services to increments depends on the service priority with the highest priority services delivered first. 72

29. Incremental development

30. 4.2.1 Incremental development advantages
Customer do not have to wait until the entire system is delivered before they can gain value from it, the first increment satisfies their most critical requirements so they can use the software immediately.
Customer can use the early increments as prototypes and gain experience that informs their requirements for later system increments.

31. There is a lower risk of overall project failure
There is a lower risk of overall project failure. Although problems may be encountered in some increments, it is likely that most of them will be successfully delivered to the customer.
As the highest priority services are delivered first, and later increments are integrated with them, it is inevitable that the most important system services receive the most testing. This means that customers are less likely to encounter software failures in the most important parts of the system. 72

32. Incremental delivery problems
Should be relatively small ( no more than 20,000 lines of code )
Each increment should deliver some system functionality.

33. 4.2.2 Spiral development
Process is represented as a spiral rather than as a sequence of activities with backtracking.
Each loop in the spiral represents a phase in the process.
No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required.
Thus the innermost loop might be concerned with system feasibility (practicability), the next loop with requirements definition, the next loop may with system designed.

34. Spiral model of the software process

35. Spiral model sectors
Each loop in the spiral is split into four sectors:
Objective setting
Specific objectives for that phase are defined. Constraints on the process and the product are identified and a detailed management plan is drawn up. Project risks are identified. Alternative strategies, depending on these risks, may be planned.
Risk assessment and reduction (reduce)
For each of the identified project risks, a detailed analysis is carried out. Steps are taken to reduce the risk. For example, if there is risk that the requirements are inappropriate, a prototype system may be developed.

36. Development and validation
After risk evaluation, a development model for the system is chosen.
If safety risks are the main consideration, development based on Formal Transformations may be the most appropriate.
If the main identified risk is sub-system integration then Waterfall model may be the most appropriate development model.
Planning
The project is reviewed and the next phase of the spiral is planned.

37. Conclusion of Spiral development
The main difference between the spiral model and other software process models is the explicit recognize of risk in the spiral model.
For example, if the intention is to use a new programming language, a risk is that the available compilers are unreliable or do not produce sufficiently efficient object code. So risk in project problems such as schedule and cost overrun so risk minimization is very important project management activity.

38. A cycle of the spiral begins by determine clear objectives
A cycle of the spiral begins by determine clear objectives. such as performance and functionality.
Alternative ways of achieving these objectives and the constraints imposed on each of the loop.
Each alternative is assessed or evaluate.
To resolve these risks by information-gathering activities such as more detailed analysis, prototyping and simulation.
Once risks have been assessed, some development is carried out, followed by a planning activity for the next phase of the process. 74

39. 4.3 Process activities Software specification
Software design and implementation
Software validation
Software evolution

40. 4.3.1 Software specification
The process of establishing what services are required and the constraints on the system’s operation and development.
Requirements engineering process
Feasibility study;
An estimate is made of whether the identified user needs may be satisfied using current software and hardware technologies, and whether the proposed system will be cost-effective from a business point of view and within existing budgetary constraints.

41. Requirements elicitation (draw out) and analysis;
This is a process of deriving the system requirements through observation of existing systems, discussions with potential users and customer, task analysis and so on.
Requirements specification;
This activity will translating the information gathered during the analysis activity into a set of requirement documents.
Requirements validation.
This activity checks the requirements for consistency and completeness .in this stage, error in the requirements document may occur, it must be modified to correct these problems.

42. The requirements engineering process

43. 4.3.2 Software design and implementation
The process of converting the system specification into an executable system.
Software design
Design a software structure that realizes the specification;
Implementation
Translate this structure into an executable program;
The activities of design and implementation are closely related and may be interleaved.

44. Design process activities
Architectural design
The sub-system making up the system and their relationships are identified and documented.
Abstract specification
For each sub-system, under its services an abstract specification and the constraints which will be produced.
Interface design
For each sub-system, its interface with other sub-systems is designed and documented. This interface specification must be clear,

45. Component design Data structure design Algorithm design
Service are assigned to components and interface of these components are designed.
Data structure design
To designed a detail and specified Data structure for the implementation system.
Algorithm design
Detail designed and specified the algorithms that used to provide service.

46. The software design process

47. Structured methods
Structured methods is approach that rely on producing graphical models of the system，include a design process model，notations to represent the design, report formats, rules and design guidelines, it may support some or all of the following models of a system:

48. Structured methods Possible models
Object model; that show the object classes used in the system and their dependencies.
Sequence model; show how objects in the system interact when the system is executing.
State transition model; shows system states and the triggers condition for the transitions from one state to another.
Structural model; to documented the system components and their aggregations.
Data-flow model. to describe the model when data transformation is processed. 78

49. Programming and debugging
Translating a design into a program and removing errors from that program.
Programming is a personal activity - there is no generic programming process.
Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process.79

50. The debugging process

51. 4.3.3 Software validation
Verification and validation (V & V) is intended to show that a system conforms (obedient) to its specification and meets the requirements of the system customer.
Involves checking and review processes and system testing.
System testing involves executing the system with test cases that are derived (gain) from the specification of the real data to be processed by the system.

52. The testing process
Figure 4.9 the testing process

53. Testing stages Component or unit testing
Individual components are tested independently;
Components may be simple entities such as functions or objects class. or may be related groupings of these entities.
System testing
The components are integrated to make up the system.
This process is concerned with finding errors that result from unanticipated (unexpected) interactions between component interface problems.
It is also concerned with validating that the system meets its functional and non-functional requirements.
For large systems, may be a multistage process where components are integrated to form sub-systems that are individually test before they are themselves integrated to form the final system.

54. Testing stages Acceptance testing
Testing with customer (real) data to check that the system meets the customer’s needs.
It may reveal errors and omissions in the system requirements definition because the real data exercise the system in different ways from the test data. 80
Usually, system development and testing are interleave.
Figure 4.10, explain how to connect with testing plain between the development and testing

55. Testing phases
Figure 4.10
Testing Phases

56. Category of Acceptance Testing
Alpha testing: custom system are developed for a single client. The Alpha testing process continues until the system developer and client agree that the delivered system is an acceptable implementation of the system requirements.
Beta testing: when a system is to be marketed as a software product, this testing process called Beta testing, it involves delivering a system to a number of potential customers who agree to use that system. Then report problems to the system developers. This exposes the product to real use and detects errors that may not have been anticipated by the system builders. 81

57. 4.3.4 Software evolution
Once a decision has been made to procure hardware, it is very expensive to make changes to the hardware design, however change can be made to software at any time during or after the system development.
As requirements change through changing business circumstances, the software that supports the business must also evolve and change.

58. Distinction between development and evolution (maintenance) is becoming increasingly irrelevant (unrelated) .
Fewer and fewer software systems are now completely new systems,
It is more realistic to think of software engineering as an evolutionary process. 82

59. System evolution
Figure 4.11
System evolution

60. 4.4 The Rational Unified Process (RUP)
A modern process model derived from the work on the UML (Unified Modeling Language) and associated process.
Normally described from 3 perspectives (viewpoint)
A dynamic perspective that shows phases over time;
A static perspective that shows process activities;
A practice perspective that suggests good practice.

61. RUP phases
RUP is a phased model that identifies four discrete (separated) phases in the software process. However, unlike the waterfall model where phases are equated with process activities, the phase of RUP are more closely related to business rather than technical concerns.
Include four stage as followed : (Dynamic view)
Inception
Establish the business case for the system. You should identify all external entities (people and system) that will interact with the system and define these interactions. You should use this information to assess the contribution that the system makes to the business. In case the contribution is minor then the project may be cancelled.

62. Dynamic view Elaboration Construction
Toe goals is Develop an understanding of the problem domain
Establish an architecture framework for the system
Identify key project risks when develop project plan
When completion of this phase, you have
Requirements model for the system (UML are specified)
Architectural description and software development plan
Construction
In this phase is essentially concerned System design, programming and testing.
Some systems are developed in parallel and integrated during this phase.
When completion, you should have a working software system and associated documentation that is ready for delivery to users.

63. Transition
Is final phase, concerned with moving the system from the development environment to the user community and making it work in a real environment.
This is a expensive and sometimes problematic activity, but is ignored in the most software process models. 83

64. Dynamic view RUP is Iteration activities and supported in two ways.
Each phase may be enacted (act) in an interative way with the results (complete) developed incrementally.
The whole set of phase may also be enacted an interative way incrementally too, as show by the looping arrow from Tasnsition to Inception in followed next Figure 4.12

65. RUP phase model

66. Workflows in the RUP description
The static view of the RUP focuses on the activities during the development process.
These are called workflows in RUP description
There are six core process workflows identified in the process and three core supporting workflows.
The RUP has been designed in conjunction with the UML (Unified Modeling Language)
The workflows show in followed figure 4.13

67. Static workflows (static view)

68. RUP describes good SE practice
Six fundamental best practices are recommended:
Develop software iteratively
Plan increments of the system based on customer requirement
Develop and deliver the highest priority system features early in the development process.
Manage requirements
Explicitly the customer’s requirements document
keep track of change the requirements
Analyse the impact of changes on the system before accepting them.

69. Use component-based architectures Visually model software
Transfer the system structure into components
Visually model software
Use graphical UML models to show static and dynamic view of the software system.
Verify software quality
Ensure that the software meets the organization quality standards.
Control changes to software
Manage changes to the software using a change management system and configuration management procedures and tools 84

70. 4.5 Computer-aided software engineering (CASE)
Computer-aided software engineering (CASE) is software to support software development and evolution processes activities.
The activities include such requirements engineering, design, program development and testing.
So case tool include design editors, data dictionaries, compilers, debuggers, system building tools and so on.

71. Case technology provides software process support by automating some process activities and by providing information about the software that is being developed.

72. Example of Activity that can be automated :
Graphical editors for system model development;
Data dictionary that holds information about the entities and relations in a design;
Generation of user interfaces from a graphical interface description that is created interactively by the user;
Program debugging through the provision of information about an executing program;
Automated translators to generate new versions of a program from an old version of a programming, language such as COBOL. 85

73. Case technology
Case technology has led to significant improvements in the software process, in fact, the improvements have been achieved 40% saved. However, it did not generate huge savings in software process costs.

74. CASE are limited by two factor :
Software engineering requires creative thought
existing CASE system can easily automate routine activities
But try to use artificial intelligence technology to provide support for design have not been successful.
Software engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support these.

75. CASE technology is now mature
In the market the CASE tools and workbenches are available from a wide range of suppliers.

76. CASE classification
Classification helps us understand the different types of CASE tools and their support for process activities.
Functional perspective
Tools are classified according to their specific function.
Process perspective
Tools are classified according to process activities that are supported.
Integration perspective
Tools are classified according to their organisation into integrated units.

77. Figure 4.14
In figure 4.14, according to functionality to classified the case tool.

78. Functional tool classification
Figure 4.14

79. Figure 4.15
It is the other way to classified to show the each step of development when use CASE tools.

80. Activity-based tool classification
Figure 4.15

81. CASE integration
The other classified way for CASE is depending on it can support the how wide of software process
Tools
Support individual process tasks such as design consistency checking, text editing, etc.
Workbenches
Support a process phase such as specification or design, Normally include a number of integrated tools.
Environments
Support all or a substantial part of an entire software process. Normally include several integrated workbenches.

82. Tools, workbenches, environments

83. Key points
Software processes are the activities involved in producing and evolving a software system.
Software process models are abstract representations of these processes.
General activities are specification, design and implementation, validation and evolution.
Generic process models describe the organisation of software processes. Examples include the waterfall model, evolutionary development and component-based software engineering.
Iterative process models describe the software process as a cycle of activities.

84. Key points
Requirements engineering is the process of developing a software specification.
Design and implementation processes transform the specification to an executable program.
Validation involves checking that the system meets to its specification and user needs.
Evolution is concerned with modifying existing system to meet new requirements. This is becoming the normal approach to software development for small and medium-sized systems.

85. More informations
Computer Aided Software Engineering (CASE tool) Computer Aided Software Engineering tools offer many benefits for developers building large-scale systems. As spiralling user requirements continue to drive system complexity to new levels, enabling us to abstract away from the entanglement of source code, to a level where architecture and design become more apparent and easier to understand and modify. The larger a project, the more important it is to use a case tool in software development. As developers interact with portions of a system designed by their colleagues, they must quickly seek a subset of classes and methods and assimilate an understanding of how to interface with them. In a similar sense, management must be able, in a timely fashion and from a high level, to look at a representation of a design and understand what's going on. For these reasons, CASE tools coupled with methodologies give us a way of representing systems too complex to comprehend in their underlying source code or schema-based form. Select Business Solutions has been developing and building these CASE tools since the late 1980s, as well as developing processes and methods to support high quality application development. Solution Breakdown Select Solution Factory a Business Process Modeling - BPM, a Unified Modeling Language - UML modeling tool, and Data Modeling CASE Tool Select Scope Manager a eXtreme Programming and Agile Modeling CASE Tool Select SSADM a Structured Systems Analysis and Design Methodology CASE Tool Select Yourdon a real time CASE Tool supporting the Yourdon, Hatley-Pirbhai and Ward-Mellor real-time extensions.   

86. The Rational Unified Process is a modern generic process model that is organised into phases (inception, elaboration, construction and transition “Dynamic perspective”) but that separates activities (requirements, analysis and design, etc. ”Static perspective”)
CASE technology provides automated supports for software process. CASE tools support individual process activities; workbenches support a set of related activities; environments support all or most software process activities.

87. End week 6

88. Week 8 testing
Could you explain how many Software process models in this chapter, and detail explain them?

89. Ans
p65

90. Exercises 4.1
giving reasons for your answer based on the type of system being developed, suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following systems:
A system to control anti-lock braking in a car.
Anti-lock braking system: Safety-critical system so method based on formal transformations with proofs of equivalence between each stage, therefore waterfall model is appropriate.

91. A virtual reality system to support software maintenance :
Virtual reality system, the system whose requirements cannot be predicted in advance so exploratory programming model is appropriate. (4.1.2) 68
A university accounting system that replaces an existing system :
System whose requirements should be stable because of existing system therefore waterfall model is appropriate.

92. An interactive system that allows railway passengers to find train times from terminals installed in stations.
System with a complex user interface but which must be stable and reliable. Should be based on throw-away prototyping to find requirements then either incremental development or waterfall model. (4.1.2) 68

93. Exercises 4.2
Explain why programs that are developed using evolutionary development are likely to be difficult to maintain.
From an engineering and management perspective, the evolutionary approach has two problems:
The process is not visible: Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost-effective to produce documents that reflect every version of the system.
Systems are often poorly structured: continual change tends to corrupt the software structure. Incorporating software changes becomes increasingly difficult and costly.

94. Exercises 4.5
Suggest why it is important to make a distinction between developing the user requirements and developing system requirements in the requirements engineering process.
User requirements (high-level abstract requirements): are statement, in a natural language plus diagrams, of what services the system is expected to provide and the constraints under which it must operate.
System requirements (detailed description of what the system should do, sometimes call a functional specification): set out the system’s functions, services and operational constraints in detail. The system requirements document should be precise (exact). It should define exactly what is to be implemented. It may be part of the contract between the system buyer and the software developers.

95. Exercises 4.6
Describe the main activities in the software design process and the outputs of these activities. Using a diagram, show possible relationships between the outputs of these activities.

96. Answer 4.6 Architectural design Abstract specification
Interface design
Component design
Data structure design
Algorithm design
The diagram as show on page 77, figure 4.7

97. Exercises 4.8
Design a process model for running system tests and recording their results. No
System stop
Running program
Recording result
Error occur
Yes
Input new data for test

98. Exercises 4.9
Explain why a software system that is used in real-world environment must change or become progressively less useful.
Systems must change because as they are installed in an environment the environment adapts to them and this adaptation naturally generates new/different system requirements. Furthermore, the system's environment is dynamic and constantly generates new requirements as a consequence (result) of changes to the business, business goals and business policies. Unless the system is adapted to reflect these requirements, its facilities will become out-of-step with the facilities needed to support the business and, hence, it will become less useful

99. Exercises 4.10
Suggest how a CASE technology classification scheme may be helpful to managers responsible for CASE system procurement
A classification scheme can be helpful for system procurement because it helps identify gaps in the CASE tool coverage in an organization. Procurement may be aimed at filling these gaps. Alternatively, a classification scheme may be used to find tools which support a range of activities - these may represent the most cost effective purchases if funds are limited.

100. Exercises 4.12
Historically, the introduction of technology has caused profound (deep) changes in the labour market and, temporarily at least, displaced (replace) people from jobs. Discuss whether the introduction of advanced CASE technology is likely to have the same consequences for software engineers. If you don’t think it will, explain why not. If you think that it will reduce job opportunities, is it ethical (moral) for the engineers affected to passively (inactive) or actively resist the introduction of this technology?

101. Ans:
There are obviously (easy understand) different views here and a lot depends on the development of CASE technology in the future. A major difference between the introduction of CASE technology and, for example, the introduction of CAD technology which made draftsmen redundant, is that the routine elements in the design and development of software are relatively minor parts of the whole development process. Therefore, savings are not that large. However, if AI (Artificial Intelligent) technology develops so that truly intelligent tools can be developed than, obviously, this situation will change.
By the way, new technology will change some job to become redundant, but in the same time, it will create new opportunity and new jobs for the new century.

102. End