Introduction

Software Engineering, 

 Slide  1

Software engineering
The economies of ALL developed nations are dependent on software
q q

More and more systems are software controlled

Software engineering is concerned with theories, methods and tools for professional software development
q

Software engineering expenditure represents a significant fraction of GNP in all developed countries
q

Software Engineering, 

 Slide  2

FAQs about software engineering
q q q

q

q q

What is software? What is software engineering? What is the difference between software engineering and computer science? What is the difference between software engineering and system engineering? What is a software process? What is a software process model?

Software Engineering, 

 Slide  3

What is software?
Software is 2. Instructions(computer programs) that when executed provide desired function and performance, 3. Data structures that enable the programs to adequately manipulate information and 4. Documents that describe the operation and use of the programs. Software is a set of utility programs which are input and stored permanently in the computer system .

Software Engineering, 

 Slide  4

Evolving role of software : The early years : •Batch orientation •Limited distribution •Custom software The second era •Multi user •Real-time •Database •Product software
Software Engineering,   Slide  5

The third era : •Distributed systems •Embedded “intelligence” •Low cost hardware •Customer impact

Software Engineering, 

 Slide  6

The fourth era : •Powerful desktop systems •Object-oriented technologies •Expert systems •Artificial neural networks •Parallel computing •Network computers
Software Engineering,   Slide  7

q q

q

Computer programs and associated documentation Software products may be developed for a particular customer or may be developed for a general market Software products may be
• • Generic - developed to be sold to a range of different customers Bespoke (custom) - developed for a single customer according to their specification

Software Engineering, 

 Slide  8

The Nature of Software Software is flexible. Software is an executable specification of a  computation. Software is expressive. All computable functions may  be expressed in software. Complex event driven systems may be  expressed in software. Software is huge. An operating system may  consist of millions of lines of code. Software is complex. Software  has little regularity or recognizable components found in other  complex systems and there are exponentially many paths through the  code and changes in one part of the code may have unintended  consequences in other equally remote sections of the code. Software  is cheap. 
Software Engineering,   Slide  9

What are the attributes of good software?
q

q

The software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable Maintainability
• Software must evolve to meet changing needs Software must be trustworthy Software should not make wasteful use of system resources Software must be usable by the users for which it was designed

q

Dependability

q

Efficiency

q

Usability

Software Engineering, 

 Slide  10

Software Applications : •System Software •Real-time Software •Business Software (Payroll,sales order processing,inventory etc.) •Engineering and Scientific Software •Embedded Software •Personal Computer Software •Artificial Intelligence Software
Software Engineering,   Slide  11

Software costs
q

q

q

Software costs often dominate system costs. The costs of software on a PC are often greater than the hardware cost Software costs more to maintain than it does to develop. For systems with a long life, maintenance costs may be several times development costs Software engineering is concerned with cost-effective software development

Software Engineering, 

 Slide  12

Manufacturing cost is zero, development cost is everything. Thus,  the first copy is the engineering prototype, the production  prototype and the finished product. Software is never finished. The  changing requirements and ease of modification permits the  maintenance phase to dominate a software product's life cycle, i.e.,  the maintenance phase consists of on going design and  implementation cycles. Software is easily modified. It is natural to  use an iterative development process combining requirements  elicitation with design and implementation and use the emerging  implementation to uncover errors in design and in the  requirements. Software is communication. Communication with a  machine but also communication between the client, the software  architect, the software engineer, and the coder. Software must be  readable in order to be evolvable.
Software Engineering,   Slide  13

What are the costs of software engineering?
q

q

q

Roughly 60% of costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs Costs vary depending on the type of system being developed and the requirements of system attributes such as performance and system reliability Distribution of costs depends on the development model that is used

Software Engineering, 

 Slide  14

Introduction
q

Getting started with software engineering

Software Engineering, 

 Slide  15

Objectives
q

q

To introduce software engineering and to explain its importance To set out the answers to key questions about software engineering

Software Engineering, 

 Slide  16

Topics covered
q

FAQs about software engineering

Software Engineering, 

 Slide  17

(IEEE) Software Engineering is 2. The application of a systematic ,disciplined , quantifiable approach to the development, operation , and maintenance of software ; that is the application of engineering to software ; 3. The study of approaches as in 1. Or It is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works effectively on real machines.
Software Engineering,   Slide  18

What is software engineering?
q

q

Software engineering is an engineering discipline which is concerned with all aspects of software production Software engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available

Software Engineering, 

 Slide  19

What are software engineering methods?
q

q

Structured approaches to software development which include system models, notations, rules, design advice and process guidance Model descriptions
• Descriptions of graphical models which should be produced Constraints applied to system models Advice on good design practice What activities to follow

q

Rules

q

Recommendations

q

Process guidance

Software Engineering, 

 Slide  20

What are the key challenges facing software engineering?
q

q

Coping with legacy systems, coping with increasing diversity and coping with demands for reduced delivery times Legacy systems
• Old, valuable systems must be maintained and updated Systems are distributed and include a mix of hardware and software There is increasing pressure for faster delivery of software

q

Heterogeneity

q

Delivery

Software Engineering, 

 Slide  21

What is the difference between software engineering and computer science?
q

q

Computer science is concerned with theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software Computer science theories are currently insufficient to act as a complete underpinning for software engineering

Software Engineering, 

 Slide  22

What is the difference between software engineering and system engineering?
q

q

System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Software engineering is part of this process System engineers are involved in system specification, architectural design, integration and deployment

Software Engineering, 

 Slide  23

What is a software process?
q

q

A set of activities whose goal is the development or evolution of software Generic activities in all software processes are:
• • • • Specification - what the system should do and its development constraints Development - production of the software system Validation - checking that the software is what the customer wants Evolution - changing the software in response to changing demands

Software Engineering, 

 Slide  24

Key points
q

Software engineering is an engineering discipline which is concerned with all  aspects of software production. Software  products  consist  of  developed  programs  and  associated  documentation.  Essential  product  attributes  are  maintainability,  dependability, efficiency and usability. The software process consists of activities which are involved in developing  software  products.  Basic  activities  are  software  specification,  development,  validation and evolution. Methods are organised ways of producing software. They include suggestions for the process to be followed, the notations to be used, rules governing the system descriptions which are produced and design guidelines.

q

q

q

Software Engineering, 

 Slide  25

A generic view of software engineering : Engineering is the analysis , design, construction , verification , and management of technical(or social) entities . Regardless of the entity that is to be engineered , the following questions must be asked and answered : •What is the problem to be solved ? •What are the characteristics of the entity that is used to solve the problem ? •How will the entity ( and the solution) be realized? •How the entity be constructed ?
Software Engineering,   Slide  26

•What approach will be used to uncover errors that were made in the design and construction of the entity ? •How will the entity be supported over the long term. When corrections , adaptations , and enhancements are requested by users of the entity .

Software Engineering, 

 Slide  27

The work associated with software engineering can be categorized into three generic phases , regardless of application area, project size , or complexity .Each phase addresses one or more of the above questions . The definition phase focuses on what . During definition phase the software developer attempts to identify what information is to be processed , what function and performance are desired , what system behavior can be expected , what interfaces are to be established , what design constraints exist , and what validation criteria are required to define a successful system.The key requirements of the system and software are identified.
Software Engineering,   Slide  28

The development phase focuses on how .During development a software engineer attempts to define how data are to be structured , how function is to be implemented as a software architecture, how procedural details are to be implemented , how interfaces are to be characterized , how the design will be translated into a programming language , and how testing will be performed . The maintenance phase focuses on change that is associated with error correction , adaptations required as the software’s environment evolves , and changes due to enhancement brought about by changing customer requirements

Software Engineering, 

 Slide  29

System Engineering

Software Engineering, 

 Slide  30

Software engineering occurs as a consequence of a process ,called system engineering .Instead of concentrating solely on software , system engineering focuses on a variety of elements , analyzing ,designing , and organizing those elements into a system that can be a product , a service or a technology for the transformation of information or control . The system engineering process is called information engineering when the context of the engineering work focuses on a business enterprise . When a product is to be built , the process is called product engineering .
Software Engineering,   Slide  31

Computer-Based Systems :

A set or arrangement of elements that are organized to accomplish some predefined goal by processing information.

The goal may be to support some business function or to develop a product that can be sold to generate business revenue .

Software Engineering, 

 Slide  32

To accomplish the goal , a computer based system makes use of variety of system elements : Software : Computer programs ,data structures , and related documentation that serve to effect the logical method , procedure , or control that is required. Hardware : Electronic devices that provide computing capability , and electromechanical devices(e.g. sensors, motors ,pumps) that provide external world function. People : Users and operators of hardware and software .

Database : A large , organized collection of information that is accessed via software .

Software Engineering, 

 Slide  33

Documentation : Manuals , forms and other descriptive information that portrays the use and/or operation of the system. Procedures : The steps that define the specific use of each system element or the procedural context in which the system resides.

Software Engineering, 

 Slide  34

Systems Requirement

Software Engineering, 

 Slide  35

System requirements The system is developed base on the requirements of the system itself (to help manage an organization) and technical requirements. There are different view points of what information system automation is like, however, we can classify them into groups: view point of the system that will be developed, information expert’s view point and user’s one. These points of view often conflict with one another, at the same time we are required to build up a successful system in which the system, information experts and end users share the same view point. Information system is a system that collects information, manages them and creates information products for its users.
Software Engineering,   Slide  36

The system's requirements: Suitable with the general strategies: Small changes in the organization’s development may result in bigger impacts on the information system’s requirements. Therefore, during the system development process, these requirements should be regularly checked for its suitability with the general strategies. Supporting decision maker: Together with hands-on experience, knowledge and anticipating ability, information system plays an important role in supporting decision making process; Competition edge: The more competitive the environment, the more demand for better systems;
Software Engineering,   Slide  37

Return on Investment: A new information system needs to show financial benefits it can bring, because decisions on investment, development costs and operation costs are based on financial analysis; More advanced evaluation techniques can be applied. These techniques take into consideration issues such as customer support, organizational effectiveness, risk, etc. Overhead control: human resource change will influence staff number, staff skills and workload. In many cases, while human resource structure is unchanged, workload and requirement for staff skills are yet much higher;

Software Engineering, 

 Slide  38

Supporting operational management: This is clear in preparing detail information, making reports quickly, which contribute to a more flexible and efficient way of management; Improving information communication: Optimizing the flow of information, preparing necessary updated information and providing users with the information; Impact of information products: Information products are final outcomes of the IT system. We need to pay special attention to requirements for information products so as to thorough analysis. These requirements shall be frequently in comparison with general strategies while developing the system; Ability to implement more quickly and better. Software Engineering,   Slide  39

Users requirements: Users are those who use the information system to manage their organizations rather than simply those who work with computers. They are the ones who master the current information system (from information sources, management requirements to the system’s shortcomings) and are future owners of the system. Thus their requirements should be respected while developing any information system.

Software Engineering, 

 Slide  40

Attention should be paid in the following issues: Easy access: The system must be able to timely access data and manipulation supports. The system: The system must be solid and stable, being able to meet staff’s requirements and provide accurate information, easy to maintain and restructure, quick in identifying and correcting mistakes; Interface: Suitable with working style of users, stable, easy to control data, independent and flexible, enabling users to approach in different ways.

Software Engineering, 

 Slide  41

Technical requirements: Technological requirements should be taken into account when designing information systems. The important points are as follows: Information volume: Information technology equipment must be suitable with the volume of information that is to be processed; Period: Everyday information which arises regularly is repetitive information that requires special care; Accuracy: Specially high accuracy is required now and then. Accuracy is important but difficult to meet; Complexity: Issues in information treatment can be processed in principle. However, due to its complexity, the current system fails to resolved the issues that need to be resolved by the new system. Software Engineering,   Slide  42

Besides the issues of the three view point groups, we would also like to remind you of the following popular issues: Incompatibility: Applications developed in different environments are often incompatible. Computers of different kinds are difficult to be connected together, making offices isolated from information processing system; Shortcomings: Lack of typical information, unfriendly interface with users, bad storage of information. Low reliability: Data is conflicted, inadequate and unamendable, information is not updated regularly; Poor resources: Inadequate ability to search for information, lack of exploitation tools for users, low information quality; Bad support: Users are not aware of what they have handy, there are no clear development strategies, development pace is slow, support is inadequate, mutual understanding is low.
Software Engineering,   Slide  43

System Modeling

Software Engineering, 

 Slide  44

System Modeling is an important element of the system engineering process . Whether the focus is on the real world view or the detailed view , the engineer creates models that :

•Define the process that serve the needs of the view under consideration . •Represent the behavior of the process and assumptions on which the behavior is based . •Explicitly define both exogenous and endogenous input to the model. •Represent all linkages (including output) that will enable the engineer to better understand the view.
Software Engineering,   Slide  45

To construct a system model , the engineer should consider a number of restraining factors :

3. Assumptions 4. Simplifications 5. Limitations 6. Constraints 7. Preferences

Software Engineering, 

 Slide  46

System Simulation : Many computer based systems interact with the real world in a reactive fashion . That is, real-world events are monitored by the hardware and software that form the computer-based system, and based on these events , the system imposes control on the machines , processes , and even people who cause the events to occur . Real time and embedded systems often fall into the reactive system category.

Software Engineering, 

 Slide  47

Business Process Engineering : The goal of business process engineering(BPE) id to define architectures that will enable a business to use information effectively.It specifies the required computer architecture , and the architecture that populates the organizations unique configuration of computing resources ,to be developed. BPE is one approach for creating an overall plan for implementing the computer architecture. Three different architectures must be analyzed and designed within the context of business objectives and goals. •Data Architecture •Application architecture •Technology architecture
Software Engineering,   Slide  48

The data architecture : It provides a framework for the information needs of a business or business function .The individual building blocks of the architecture are the data objects that are used by the business . A data object contains a set of attributes that define some aspect , quality , characteristic , or descriptor of the data that are being described. The application architecture : It encompasses those elements of a system that transform objects within the data architecture for some business purpose . The technology architecture : It provides the foundation for the data and application architects .The infrastructure encompasses the hardware and software that are used to support the applications and data .This includes computers , operating systems , networks , telecommunication links , storage technologies , and the architecture (e.g., client/server) that has been designed to implement these technologies. Software Engineering,   Slide  49

Product Engineering : The goal of product engineering is to translate the customer’s desire for a set of defined capabilities into a working product .To achieve this goal, product engineering like business process engineering – must derive architecture and infrastructure .The architecture encompasses four distinct system components : software , hardware , data (and databases) , and people. A support infrastructure is established and includes the technology required to tie the components together and the information (e.g., documents, CD-ROM,video) that is used to support the components.

Software Engineering, 

 Slide  50

Software Processes (Process Models)

Software Engineering, 

 Slide  51

Software Processes
q

Coherent sets of activities for specifying, designing, implementing and testing software systems

Software Engineering, 

 Slide  52

Objectives
q q

q

q

To introduce software process models To describe a number of different process models and when they may be used To describe outline process models for requirements engineering, software development, testing and evolution To introduce CASE technology to support software process activities

Software Engineering, 

 Slide  53

Software Process Model : To solve the actual problems in an industry setting , a software engineer or a team of engineers must incorporate a development strategy that encompasses the process methods and tools and generic phases . This strategy is often referred as a process model or a software engineering paradigm. A process model for software engineering is chosen based on nature of the project and application , the tools to be used , and the controls and deliverables that are required.

Software Engineering, 

 Slide  54

What is a software process model?
q

q

A simplified representation of a software process, presented from a specific perspective Examples of process perspectives are
• • • Workflow perspective - sequence of activities Data-flow perspective - information flow Role/action perspective - who does what Waterfall Evolutionary development Formal transformation Integration from reusable components

q

Generic process models
• • • •

Software Engineering, 

 Slide  55

Generic software process models
q q q

System Development Life Cycle Model Prototyping Model The waterfall model
• Separate and distinct phases of specification and development Specification and development are interleaved A mathematical system model is formally transformed to an implementation The system is assembled from existing components

q

Evolutionary development

q

Formal systems development

q

Reuse-based development

Software Engineering, 

 Slide  56

Classical System Development Life Cycle : The System development life cycle method consists of the following activities : 3. Preliminary investigation 4. Determination of system requirements 5. Design of system 6. Development of software 7. System testing 8. Implementation and evaluation

Software Engineering, 

 Slide  57

Preliminary Investigation : A request to receive assistance from information systems can be made for many reasons , but in each case someone – a manager , an employee , or a system specialist – initiates the request . When the request is made , the first system activity, the preliminary investigation , begins .This activity has three parts : 4. Request classification 5. Feasibility study 6. Request approval
Software Engineering,   Slide  58

Request Clarification : Many requests from employees and users in organization are not clearly stated . Therefore, before any systems investigation can be considered , the project request must be examined to determine precisely what the originator wants . Feasibility Study : An important outcome of the preliminary investigation is the determination that the system requested is feasible . There are three aspects in the feasibility study portion of the preliminary investigation : 3. Technical Feasibility 4. Economic Feasibility 5. Operating Feasibility
Software Engineering,   Slide  59

Technical Feasibility : Can the work of the project be done with current equipment , existing software technology , and available personnel ? If new technology is required , what is the likelihood that it can be developed? Economic Feasibility : Are there sufficient benefits in creating the system to make the cost acceptable ? Or , are the costs of not creating the system so great that the project must be undertaken ? Operational Feasibility : Will the system be used if it is developed and implemented ? Will there be resistance from users that will undermine the possible application benefits.
Software Engineering,   Slide  60

Request Approval :Not all requested projects are desirable or feasible .Some organizations receive so many project requests from employees that only a few of them can be pursued.However, those projects that are both feasible and desirable should be put into a schedule.

Software Engineering, 

 Slide  61

Determination of System Requirements :Analysts, working closely with employees and managers , must study the business process to answer the key questions : 2. What is being done ? 3. How is it being done ? 4. How frequently does it occur ? 5. How great is the volume of transactions or decisions ? 6. How well is the task being performed? 7. Does the problem exist? 8. If the problem exists , how serious it is ? 9. If the problem exists , what is the underlying cause?
Software Engineering,   Slide  62

Design of system : The design of information system produces the details that state how a system will meet the requirements identified during systems analysis . Systems specialists often refer this stage as logical design, in contrast to the process of developing program software is referred as physical design. The design process will begin by identifying reports and other outputs the system will produce . Then the specific data on each are pinpointed. The detailed design information is passed on to the programming staff so that software development can begin.

Software Engineering, 

 Slide  63

Development of Software : Software developers may install (or modify and then install) purchased software or they may write new, custom-designed programs. The choice depends on the cost of each option, the time available to write software, and the availability of programmers. Programmers are also responsible for documenting the program, providing an explanation of how and why certain procedures are coded in specific ways. Documentation is essential to test the program and carry on maintenance once the application has been installed.

Software Engineering, 

 Slide  64

Systems Testing :During systems testing, the system is used experimentally to ensure that the software does not fail, I.e., it will run according to its specifications and in the way users expect . Special test data are input for processing , and the results examined. A limited number of users may be allowed to use the system so analyst can see whether they try to use it in unforeseen ways.It is preferable to discover any surprises before the organization implements the system and depends on it. In many organizations, testing is performed by persons other than those who wrote the original programs to ensure more complete and unbiased testing and more reliable software.
Software Engineering,   Slide  65

Implementation and evaluation : Implementation is the process of having systems personnel check out and put new equipment into use , train users , install new application , and construct any files of data needed to use it. Evaluation of the system is performed to identify its strengths and weaknesses . The actual evaluation can occur along any of the following dimensions : •Operational Evaluation •Organizational Impact •User Manager Assessment •Development Performance.
Software Engineering,   Slide  66

***

Software Prototyping

Software Engineering, 

 Slide  67

Software Prototyping
q

Rapid software development to validate requirements

Software Engineering, 

 Slide  68

Prototyping process
Establish prototype objectives Define prototype functionality

Develop prototype

Evaluate prototype

Prototyping plan

Outline definition

Executable prototype

Evaluation report

Software Engineering, 

 Slide  69

Objectives
q

q q

q

To describe the use of prototypes in different types of development project To discuss evolutionary and throw-away prototyping To introduce three rapid prototyping techniques - highlevel language development, database programming and component reuse To explain the need for user interface prototyping

Software Engineering, 

 Slide  70

Topics covered
q q q

Prototyping in the software process Prototyping techniques User interface prototyping

Software Engineering, 

 Slide  71

System prototyping
q q

q

Prototyping is the rapid development of a system In the past, the developed system was normally thought of as inferior in some way to the required system so further development was required Now, the boundary between prototyping and normal system development is blurred and many systems are developed using an evolutionary approach

Software Engineering, 

 Slide  72

Uses of system prototypes
q

The principal use is to help customers and developers understand the requirements for the system
• • Requirements elicitation. Users can experiment with a prototype to see how the system supports their work Requirements validation. The prototype can reveal errors and omissions in the requirements

q

Prototyping can be considered as a risk reduction activity which reduces requirements risks

Software Engineering, 

 Slide  73

Prototyping benefits
q

q

q q

q

Misunderstandings between software users and developers are exposed Missing services may be detected and confusing services may be identified A working system is available early in the process The prototype may serve as a basis for deriving a system specification The system can support user training and system testing

Software Engineering, 

 Slide  74

Prototyping benefits
q q q q q

Improved system usability Closer match to the system needed Improved design quality Improved maintainability Reduced overall development effort

Software Engineering, 

 Slide  75

Prototyping in the software process
q

Evolutionary prototyping
• An approach to system development where an initial prototype is produced and refined through a number of stages to the final system A prototype which is usually a practical implementation of the system is produced to help discover requirements problems and then discarded. The system is then developed using some other development process

q

Throw-away prototyping

Software Engineering, 

 Slide  76

Prototyping objectives
q

q

The objective of evolutionary prototyping is to deliver a working system to end-users. The development starts with those requirements which are best understood. The objective of throw-away prototyping is to validate or derive the system requirements. The prototyping process starts with those requirements which are poorly understood

Software Engineering, 

 Slide  77

Approaches to prototyping
Evolutionary prototyping Outline Requirements Throw­away Prototyping Executable Prototype + System Specification Delivered system

Software Engineering, 

 Slide  78

Evolutionary prototyping
q

q q

Must be used for systems where the specification cannot be developed in advance e.g. AI systems and user interface systems Based on techniques which allow rapid system iterations Verification is impossible as there is no specification. Validation means demonstrating the adequacy of the system

Software Engineering, 

 Slide  79

Systems Prototype Method : This method involves the user more directly in the analysis and design experience than SDLC method. Prototyping is very effective under the correct circumstances .

A prototype is a working system that is developed to test ideas and assumptions about the new system. Like any computerbased system . It consists of working software that accepts input, perform calculations, produces printed or displayed information , or performs meaningful activities.It is the first version or iteration of an information system - an original model.
Software Engineering,   Slide  80

The design and the information produced by the system are evaluated by users. This can be effectively done only if the data are real and the situations live. Changes are expected as the system is used. The prototype is actually a pilot test model; the design evolves through use. The prototype is designed to be easily changed.Information gained through its use is applied to a modified design that may again be used as a prototype to reveal still more valuable design information. The process is repeated as many times as necessary to reveal essential design requirements.
Software Engineering,   Slide  81

The prototype is most useful under following conditions : • No system with the characteristics of the one proposed has yet been constructed by the developers. •The essential features of the system are only partially known; others are not identifiable even though careful analysis of requirements. •Experience in using the system will significantly add to the list of requirements the system should meet . •Alternative versions of the system will evolve through experience and additional development and refinement of its features. •The system user(s) will participate in the development process.
Software Engineering,   Slide  82

Underlying principle of prototyping :

Users can point to features that like or dislike and so indicate shortcomings in an exiting and working system more easily than they can describe them in a theoretical or proposed system.Experience and use produce more meaningful comment than analysis of charts and narrative proposals .

Software Engineering, 

 Slide  83

Steps in prototyping : 2. Identify the user’s known information requirements and features needed in the system. 3. Develop a working prototype. 4. Use the prototype , noting needed enhancements and changes.These expand the list of known system requirements. 5. Revise the prototype based in information gained through user experience. 6. Repeat these steps as needed to achieve a satisfactory system.
Software Engineering,   Slide  84

When both user and analyst decide that sufficient information has been collected from the prototyping process, they determine how to meet the requirements they have identified. Usually one of the following four alternatives is selected : 2. 3. The prototype is redeveloped . This alternative may mean complete reprogramming from scratch. The prototype is implemented as the complete system. Performance efficiency and methods for user interaction may be sufficient to allow the system to be used as is. The project is abandoned . In this case the prototype has provided enough information to show that a system cannot be developed to meet the desired objectives within existing technology or economic or operational guidelines. Another prototyping series begun.The information gained through the current experience may suggest an entirely different approach to contrasting features.

4.

5.

Each alternative is viewed as a successful result of prototyping.
Software Engineering,   Slide  85

Waterfall model
Requirements definition System and software design Implementation and unit testing Integr ation and system testing Operation and maintenance
Software Engineering,   Slide  86

Waterfall model phases
q q q q q q

Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance The drawback of the waterfall model is the difficulty of accommodating change after the process is underway

Software Engineering, 

 Slide  87

Waterfall model problems
q q

q

Inflexible partitioning of the project into distinct stages This makes it difficult to respond to changing customer requirements Therefore, this model is only appropriate when the requirements are well-understood

Software Engineering, 

 Slide  88

Evolutionary development
q

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 Objective is to understand the system requirements. Should start with poorly understood requirements

q

Throw-away prototyping

Software Engineering, 

 Slide  89

Evolutionary Software Process Models :

3. The Incremental Model 4. The Spiral Model 5. The Component assembly model 6. The concurrent development model

Software Engineering, 

 Slide  90

The Incremental Model : It combines elements of the linear sequential model with the iterative philosophy of prototyping Each linear sequence produces a deliverable “increment” of a software . When an incremental model is used , the first increment is often a core product . That is, basic requirements are addressed , but many supplementary features (some known,others unknown) remain undelivered.The core product is used by the customer (or undergoes detailed review).As a result of use and/or evaluation , a plan is developed for next increment .The plan addresses the modification of the core product to better meet the needs of the customer and the delivery of additional features and functionality .This process is repeated following the delivery of each increment , until the complete product is produced.
Software Engineering,   Slide  91

Incremental development
q

q

q

Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality User requirements are prioritised and the highest priority requirements are included in early increments Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve

Software Engineering, 

 Slide  92

Incremental development
Define outline  requirements Design system architecture

Assign requirements       to increments

Develop system increment

Valida te increment System incomplete

Integrate increment

Valida te system Final system

Software Engineering, 

 Slide  93

Incremental development advantages
q

q

q q

Customer value can be delivered with each increment so system functionality is available earlier Early increments act as a prototype to help elicit requirements for later increments Lower risk of overall project failure The highest priority system services tend to receive the most testing

Software Engineering, 

 Slide  94

Extreme programming
q

q

New approach to development based on the development and delivery of very small increments of functionality Relies on constant code improvement, user involvement in the development team and pairwise programming

Software Engineering, 

 Slide  95

Spiral development
q

q

q

q

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 Risks are explicitly assessed and resolved throughout the process

Software Engineering, 

 Slide  96

The Spiral Model : The spiral model is a software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model .It provides the potential for rapid development of incremental versions of the software .In the spiral model , software is developed in a series of incremental releases .During early iterations , the incremental release might be a paper model or prototype. During later iterations , increasingly more complete versions of the engineered versions are produced.

Software Engineering, 

 Slide  97

Spiral model of the software process
Determine objectives alternatives and constraints Risk analysis Risk analysis Risk analysis Prototype 3 Prototype 2 Opera­ tional proto ype Evaluate alternatives identify, resolve risks

REVIEW Requirements plan Life­cycle plan

Risk anal sis Proto­ y type 1 Concept of Operation

Simulations, models, benchmarks S/W requirements Product design

Development plan Integration and test plan

Plan next phase

Code Unit test Design V&V Integr ation test Acceptance test Develop, verify Service next­level product

Requirement validation

Detailed design

Software Engineering, 

 Slide  98

The spiral model is divided into a number of framework activities , also called task regions . •Customer communications – tasks required to establish effective communications between developer and customer. •Planning –tasks required to define resources , timeliness and other project related information. •Risk analysis –tasks required to access both technical and management risks. •Engineering – tasks required to build one or more representations of the application. •Construction and release – tasks required to construct , test , install and provide use support. •Customer evaluation – tasks required to obtain customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation stage.
Software Engineering,   Slide  99

Spiral model sectors
q

Objective setting
• Specific objectives for the phase are identified Risks are assessed and activities put in place to reduce the key risks A development model for the system is chosen which can be any of the generic models The project is reviewed and the next phase of the spiral is planned

q

Risk assessment and reduction

q

Development and validation

q

Planning

Software Engineering, 

 Slide  100

The component assembly model : The component object model incorporates many of the characteristics of the spiral model .It is evolutionary in nature , demanding an iterative approach to the creation of software .The component assembly model composes applications from prepackaged software components (sometimes called “classes”).

Software Engineering, 

 Slide  101

Component and application assembly
q

q

q

Prototypes can be created quickly from a set of reusable components plus some mechanism to ‘glue’ these component together The composition mechanism must include control facilities and a mechanism for component communication The system specification must take into account the availability and functionality of existing components

Software Engineering, 

 Slide  102

The Concurrent Development Model : The concurrent process model can be represented schematically as a series of major technical activities , tasks , and their associated states . The concurrent process model defines a series of events that will trigger transitions from state to state for each of the software engineering activities .

Software Engineering, 

 Slide  103

The RAD Model : Rapid Action Development is a linear sequential software development process model that emphasizes an extremely short development cycle. If requirements are well understood and project scope is constrained the RAD process enables a development team to create a “fully functional system” within very short time periods . The RAD approach encompasses the following phases : •Business Modeling : The information flow among business functions is modeled in a way that answers the following questions . What drives the business process ? What information is generated ? Where does the information go ? Who processes it ?
Software Engineering,   Slide  104

•Data modeling :The information flow defined as part of business modeling phase is refined into a set of data objects that are needed to support the business . The characteristics (called attributes) of each object are identified and the relationships between these objects are defined . •Process modeling : The data object defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function. •Application generation :The RAD process works to reuse existing program components(when possible) to create reusable components (when necessary). Automated tools are used to facilitate construction of software.
Software Engineering,   Slide  105

•Testing and turnover : Since the RAD process emphasizes reuse , many of the program components have already been tested . This reduces overall testing time.However , new components must be tested and all interfaces must be fully exercised.

RAD is not appropriate when technical risk is high .This occurs when a new application makes heavy use of technology or when the new software requires high degree of interoperability with existing computer programs.

Software Engineering, 

 Slide  106

Software design and implementation
q

q

The process of converting the system specification into an executable system Software design
• Design a software structure that realises the specification Translate this structure into an executable program

q

Implementation

q

The activities of design and implementation are closely related and may be inter-leaved

Software Engineering, 

 Slide  107

Software validation
q

q

q

Verification and validation is intended to show that a system conforms 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 from the specification of the real data to be processed by the system

Software Engineering, 

 Slide  108

The testing process
Unit testing Module testing

Sub­system testing

System testing Acceptance testing

Component testing
Software Engineering,   Slide  109

Integration testing

User testing

Testing stages
q

Unit testing
• Individual components are tested Related collections of dependent components are tested Modules are integrated into sub-systems and tested. The focus here should be on interface testing Testing of the system as a whole. Testing of emergent properties Testing with customer data to check that it is acceptable

q

Module testing

q

Sub-system testing

q

System testing

q

Acceptance testing

Software Engineering, 

 Slide  110

Testing phases
Requir ements specification System specification System design Detailed design

Acceptance test plan

System integration test plan

Sub­system integration test plan

Module and unit code and tess

Service

Acceptance test

System integration test

Sub­system integration test

Software Engineering, 

 Slide  111

Software evolution
q q

q

Software is inherently flexible and can change. As requirements change through changing business circumstances, the software that supports the business must also evolve and change Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new

Software Engineering, 

 Slide  112

Computer Aided Systems Engineering
Software Engineering,   Slide  113

CASE tools generally include five components :

3. Diagramming tools 4. An information repository 5. Interface generators 6. Code generators and 7. Management tools

Software Engineering, 

 Slide  114

Diagramming Tools : These tools support analysis and documentation of application requirements . Typically, they include the capabilities to produce data flow diagrams , data structure diagrams , and program structure charts . They support the capability to draw diagrams and charts , and to store details internally .

Software Engineering, 

 Slide  115

Centralized Information Repository : The capture , analysis , processing , and distribution of all systems information is aided by centralized information repository or data dictionary. The dictionary contains details of system components , such as data items, data flows , and processes and also include information describing the volume and frequency of each activity.

Software Engineering, 

 Slide  116

Interface Generators : System interfaces are means by which users interact with an application , both to enter information and data or to receive information . Interface generators provide the capability to prepare prototypes of user interfaces. They support the rapid creation of demonstration system menus , presentation screens , and report layouts.

Software Engineering, 

 Slide  117

Code Generators : Code generators automate the preparation of computer software . They incorporate methods that allow the conversation of system specifications into executable source code.

Software Engineering, 

 Slide  118

Management Tools : CASE systems also assist project managers in maintaining efficiency and effectiveness throught the application development process . This CASE component assist development managers in scheduling of analysis and design activities and the allocation of resources to different project activities.

Software Engineering, 

 Slide  119

Automated process support (CASE)
q

q

Computer-aided software engineering (CASE) is software to support software development and evolution processes Activity automation
• • • • • Graphical editors for system model development Data dictionary to manage design entities Graphical UI builder for user interface construction Debuggers to support program fault finding Automated translators to generate new versions of a program

Software Engineering, 

 Slide  120

Case technology
q

Case technology has led to significant improvements in the software process though not the order of magnitude improvements that were once predicted
• • Software engineering requires creative thought - this is not readily automatable Software engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support these

Software Engineering, 

 Slide  121

CASE classification
q

q

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 Tools are classified according to process activities that are supported Tools are classified according to their organisation into integrated units

q

Process perspective

q

Integration perspective

Software Engineering, 

 Slide  122

CASE integration
q

Tools
• Support individual process tasks such as design consistency checking, text editing, etc. Support a process phase such as specification or design, Normally include a number of integrated tools Support all or a substantial part of an entire software process. Normally include several integrated workbenches

q

Workbenches

q

Environments

Software Engineering, 

 Slide  123

Key points
q

q

q

q

Software processes are the activities involved in producing and evolving a software system. They are represented in a software process model General activities are specification, design and implementation, validation and evolution Generic process models describe the organisation of software processes Iterative process models describe the software process as a cycle of activities

Software Engineering, 

 Slide  124

Key points
q

q

q

q

q

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 the system after it is in use CASE technology supports software process activities

Software Engineering, 

 Slide  125

Software Requirements

Software Engineering, 

 Slide  126

Software Requirements
q

Descriptions and specifications of a system

Software Engineering, 

 Slide  127

Objectives
q

q q

q

To introduce the concepts of user and system requirements To describe functional and non-functional requirements To explain two techniques for describing system requirements To explain how software requirements may be organised in a requirements document

Software Engineering, 

 Slide  128

Topics covered
q q q q

Functional and non-functional requirements User requirements System requirements The software requirements document

Software Engineering, 

 Slide  129

Requirements engineering
q

q

The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process

Software Engineering, 

 Slide  130

What is a requirement?
q

q

It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification This is inevitable as requirements may serve a dual function
• • • May be the basis for a bid for a contract - therefore must be open to interpretation May be the basis for the contract itself - therefore must be defined in detail Both these statements may be called requirements

Software Engineering, 

 Slide  131

Types of requirement
q

User requirements
• Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor A detailed software description which can serve as a basis for a design or implementation. Written for developers

q

System requirements

q

Software specification

Software Engineering, 

 Slide  132

Definitions and specifications
Requirements definition 1. The software must provide a means of repr esenting and 1. accessing external files created by other tools. Requirements specification 1.1 The user should be provided with facilities to define the type of 1.2 external files. 1.2 Each external file type may have an associated tool which may be 1.2 applied to the file. 1.3 Each external file type may be represented as a specific icon on 1.2 the user’s display. 1.4 Facilities should be provided for the icon repr esenting an 1.2 external file type to be defined by the user. 1.5 When a user selects an icon repr esenting an external file, the 1.2 effect of that selection is to apply the tool associated with the type of 1.2 the external file to the file represented by the selected icon.
Software Engineering,   Slide  133

Requirements readers
User requirements Client managers System end­users Client engineers Contractor managers System architects System end­users Client engineers System architects Software developers Client engineers (perhaps) System architects Software developers

System requirements

Software design specification
Software Engineering,   Slide  134

Functional and non-functional requirements
q

Functional requirements
• Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations. constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. Requirements that come from the application domain of the system and that reflect characteristics of that domain

q

Non-functional requirements

q

Domain requirements

Software Engineering, 

 Slide  135

Functional requirements
q q

q

Describe functionality or system services Depend on the type of software, expected users and the type of system where the software is used Functional user requirements may be high-level statements of what the system should do but functional system requirements should describe the system services in detail

Software Engineering, 

 Slide  136

Examples of functional requirements
q

The user shall be able to search either all of the initial set of databases or select a subset from it. The system shall provide appropriate viewers for the user to read documents in the document store. Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.

q

q

Software Engineering, 

 Slide  137

Requirements imprecision
q

q

q

Problems arise when requirements are not precisely stated Ambiguous requirements may be interpreted in different ways by developers and users Consider the term ‘appropriate viewers’
• • User intention - special purpose viewer for each different document type Developer interpretation - Provide a text viewer that shows the contents of the document

Software Engineering, 

 Slide  138

Requirements completeness and consistency
q

q

In principle requirements should be both complete and consistent Complete
• They should include descriptions of all facilities required There should be no conflicts or contradictions in the descriptions of the system facilities

q

Consistent

q

In practice, it is impossible to produce a complete and consistent requirements document

Software Engineering, 

 Slide  139

Non-functional requirements
q

q

q

Define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc. Process requirements may also be specified mandating a particular CASE system, programming language or development method Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless

Software Engineering, 

 Slide  140

Non-functional classifications
q

Product requirements
• Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc. Requirements which are a consequence of organisational policies and procedures e.g. process standards used, implementation requirements, etc. Requirements which arise from factors which are external to the system and its development process e.g. interoperability requirements, legislative requirements, etc.

q

Organisational requirements

q

External requirements

Software Engineering, 

 Slide  141

Non-functional requirement types
Non­functional requir ements Product requir ements Or ganizational requir ements External requirements

Ef ficiency requir ements

Reliability requir ements

Portability requirements

Interoperability requirements

Ethical requirements

Usability requirements

Delivery requirements

Implementation requir ements

Standards requirements

Legislative requirements

Performance requirements

Space requir ements
 Slide  142

Privacy requirements

Safety requirements

Software Engineering, 

Goals and requirements
q

q

Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify. Goal
• A general intention of the user such as ease of use A statement using some measure that can be objectively tested

q

Verifiable non-functional requirement

q

Goals are helpful to developers as they convey the intentions of the system users

Software Engineering, 

 Slide  143

Examples
q

A system goal
• The system should be easy to use by experienced controllers and should be organised in such a way that user errors are minimised. Experienced controllers shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day.

q

A verifiable non-functional requirement

Software Engineering, 

 Slide  144

Requirements measures
Property Speed Size Ease of use Reliability Measure Processed transactions/second User/Event response time Screen refresh time K Bytes Number of RAM chips Training time Number of help frames Mean time to failure Probability of unavailability Rate of failure occurrence Availability Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Percentage of target dependent statements Number of target systems
 Slide  145

Robustness Portability
Software Engineering, 

Requirements interaction
q

q

Conflicts between different non-functional requirements are common in complex systems Spacecraft system
• • • To minimise weight, the number of separate chips in the system should be minimised To minimise power consumption, lower power chips should be used However, using low power chips may mean that more chips have to be used. Which is the most critical requirement?

Software Engineering, 

 Slide  146

Domain requirements
q

q

q

Derived from the application domain and describe system characterisics and features that reflect the domain May be new functional requirements, constraints on existing requirements or define specific computations If domain requirements are not satisfied, the system may be unworkable

Software Engineering, 

 Slide  147

Domain requirements problems
q

Understandability
• • Requirements are expressed in the language of the application domain This is often not understood by software engineers developing the system Domain specialists understand the area so well that they do not think of making the domain requirements explicit

q

Implicitness

Software Engineering, 

 Slide  148

User requirements
q

q

Should describe functional and non-functional requirements so that they are understandable by system users who don’t have detailed technical knowledge User requirements are defined using natural language, tables and diagrams

Software Engineering, 

 Slide  149

Problems with natural language
q

Lack of clarity
• Precision is difficult without making the document difficult to read Functional and non-functional requirements tend to be mixedup Several different requirements may be expressed together

q

Requirements confusion

q

Requirements amalgamation

Software Engineering, 

 Slide  150

Requirement problems
q

Database requirements includes both conceptual and detailed information
• • Describes the concept of configuration control facilities Includes the detail that objects may be accessed using an incomplete name

q

Grid requirement mixes three different kinds of requirement
• • • Conceptual functional requirement (the need for a grid) Non-functional requirement (grid units) Non-functional UI requirement (grid switching)

Software Engineering, 

 Slide  151

Guidelines for writing requirements
q q

q

q

Invent a standard format and use it for all requirements Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements Use text highlighting to identify key parts of the requirement Avoid the use of computer jargon

Software Engineering, 

 Slide  152

The requirements document
q

q

q

The requirements document is the official statement of what is required of the system developers Should include both a definition and a specification of requirements It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it

Software Engineering, 

 Slide  153

Requirements document requirements
q q q q q

q

Specify external system behaviour Specify implementation constraints Easy to change Serve as reference tool for maintenance Record forethought about the life cycle of the system i.e. predict changes Characterise responses to unexpected events

Software Engineering, 

 Slide  154

Requirements document structure
q q q q q q q q q

Introduction Glossary User requirements definition System architecture System requirements specification System models System evolution Appendices Index

Software Engineering, 

 Slide  155

User-computer interface design

Software Engineering, 

 Slide  156

What is an Interface ?

An interface is the common boundary between the user and the computer system application- the point where the computer and the individual interact . Its features influence the effectiveness of the user of the system , as well as the frequency of mistakes and errors when entering data or instructions.

Software Engineering, 

 Slide  157

Purpose of interface : The interface should be designed so as to accomplish the following purposes : •Tell the system what actions to take •Facilitate use of the system •Avoid user errors

Common interface devices in online system are keyboard, mouse, light pen , scanner , touch screen , or voice.
Software Engineering,   Slide  158

Design of Input : The designer decides the following input details : 3. What data to input 4. What medium to use 5. How the data should be arranged or coded 6. The dialogue to guide users in providing input 7. Data items and transactions needing validation to detect errors 8. Methods for performing input validations and steps to follow when errors occur
Software Engineering,   Slide  159

The design decisions for handling input specify how data are accepted for computer processing. Analysts decide whether the data are entered directly, or using source documents . Online systems include a dialogue or conversation between the user and the system . Through the dialogue , users request system services and tell the system when to perform certain functions The arrangement of messages and comments in online conversations , as well as the placement of data , headings, and titles on display screens or source documents , is also a part of system design .
Software Engineering,   Slide  160

Design of Output :

Output generally refers to the results and information that are generated by the system . For many end-users, output is the main reason for developing the system and the basis on which they will evaluate the usefulness of the application . Most end-users will not actually operate the system , but they will use the output from the system.

Software Engineering, 

 Slide  161

When designing the output , the following tasks must be accomplished : •Determine what information to present •Decide whether to display , print , or “speak” the information and select the output medium •Arrange the presentation of information in an acceptable format •Decide how to distribute the output to intended recipients The arrangement of information on a display or printed document is termed as layout.
Software Engineering,   Slide  162

Menu – Driven Dialogue : Since online systems provide several input and processing options to users, a method is needed to show users , a method is needed to show users the available alternatives. Menu serves this purpose ..A menu is an exhaustive list of available system functions that are displayed on the terminal or workstation so the user can choose among them . Dialogues that use this method of interaction are said to be menu driven.

Software Engineering, 

 Slide  163

Investigation Methods
Software Engineering,   Slide  164

Fact Finding Techniques : The specific methods analysts use for collecting data about requirements are called fact-finding techniques . These include 3. The interview 4. Questionnaire 5. Record inspections (on-site review) 6. Observation

Software Engineering, 

 Slide  165

Most of the difficulties one can meet in system analysis result from the survey process. Some people perceive incorrectly that the survey process is finished after the questions on the current system and the future system have been answered and the answers have been analyzed. In fact, all information reflecting the current situation have to be collected, and it requires great effort so as to decide what information to collect and how to collect it.

Software Engineering, 

 Slide  166

Survey methods: The contexts in which you make interviews are often different and unpredictable. However, interviews are the main source of information about the future system and the current system.

Software Engineering, 

 Slide  167

There are 2 main reasons for interview failures: (ii)interviewer fails to understand what users say, (iii) bad communications between interviewer and interviewee.
Software Engineering,   Slide  168

Observation methods: Official observation: It’s not a good method to observe every single elements while collecting information to develop the system. The future system you’re building up may be deemed to change the current way of working. Moreover, those you’re looking at may feel uncomfortable and may behave unusually, which will affect your survey’s quality.

Software Engineering, 

 Slide  169

Unofficial observation: In order to get an overview of an organization, take a look at its pile of paper and document, interruption of work, unreasonable timing and positive reflection of a good working environment... It’s also important to know the quantity and quality of data that need to be processed and predict how they change over the time. Researching through document is the final good method to get important information.

Software Engineering, 

 Slide  170

Questionnaire method: This method requires your clear instructions to the user. A questionnaire can be designed base on the following points: Title: describe the objectives and main contents; Data classification: categories of data that will be used; Data: contents of the data in each category. In general, this method is complicated and ineffective for inexperienced analyzers.
Software Engineering,   Slide  171

It’s clear that each method has its own strong and weak points and is suitable for a particular context. However, regardless what method you use, the general principle is: The more information you get about the operation environment of an organization, the more you understand its issues and be able to make realistic questions about the matters you’re interested in. Information can be divided into 3 groups: General information of the organization’s vertical structure, information about the organization and information about the units that directly relate to the current issues
Software Engineering,   Slide  172

Tools for Documenting Procedures and Decisions: Decision Concepts : When analyzing procedures and decisions , the analyst must start by identifying conditions and actions – concepts common to all activities. Conditions and decision variables : Conditions : What are the possibilities ? What can happen ? ( the possible states of an entity) Conditions vary , which is why analysts may refer to them as decision variables .
Software Engineering,   Slide  173

Actions : When all possible conditions are known, the analyst next determines what to do when certain conditions occur. Actions are alternatives- the steps , activities , or procedures that an individual may decide to take when confronted with a set of conditions . The actions can be quiet simple in some cases and extensive in others . Actions can also be related to quantitative conditions . In many procedures , analyst must consider combinations of conditions and actions . To assist them in understanding and matching combinations , they use decision trees, decision tables , and structured english.

Software Engineering, 

 Slide  174

Decision –Tree Characteristics : A decision tree is a diagram that presents conditions and actions sequentially and thus shows which conditions to conditions to consider first , which second , and so on. It is also a method of showing the relationship of each condition and its permissible actions. The root of the tree , on the left of the diagram , is the starting point of the decision sequence . The particular branch followed depends on the conditions that exist and the decision to be made . Progression from left to right along a particular branch is the result of making a series of decisions . Following each decision point is the next set of decisions to be considered . The nodes of the tree thus represent conditions and indicate that a determination must be made about which condition exist before next path can be chosen .The right side of the tree lists the actions to be taken depending on sequence of conditions that is followed.
Software Engineering,   Slide  175

Using Decision Trees : Developing decision trees is beneficial to analysts in two ways . First of all , the need to describe conditions and actions forces analysts to formally identify the actual decisions that must be made . It becomes difficult for them to overlook an integral step in the decision process, whether it depends on quantitative or non quantitative variables. Decision trees also force analysts to consider the sequence of decisions.

Software Engineering, 

 Slide  176

Decision Trees
q

Graphical way of depicting if-then-else logic

Software Engineering, 

 Slide  177

Decision Tables : A decision table is a matrix of rows and columns , rather than a tree that shows conditions and actions . Decision rules , included in a decision table , state what procedures to follow when certain conditions exist.

Software Engineering, 

 Slide  178

Decision Table Characteristics : The decision table is made up of four sections : Condition statements , condition entries , action statements ,and action entries . The condition statement identifies the relevant conditions . Condition entries tell which value. If any , applies for a particular condition. Action statements lists the set of all steps that can be taken when a certain condition occurs . Action entries show what specific actions in the set take when selected conditions or combinations of conditions are true.

Software Engineering, 

 Slide  179

Structured English : It is an additional method to overcome problem of ambiguous language in stating the conditions and actions in decisions and procedures .This method doses not use trees or tables , but rather narrative statements , to describe a procedure .It does not show decision rules : It states them . Structured English uses three basic types of statements to describe a process : sequence structures, decision structures , and iteration structures. They work well for decision analysis and can be carried over into programming and software development .

Software Engineering, 

 Slide  180

Structured English
Common Statements Action Statement Example Profits = Revenues - Expenses Generate Inventory Report Add Product record to Product Data Store IF Customer Not in Customer Data Store THEN Add Customer record to Customer Data Store ELSE Add Current Sale to Customer’s Total Sales Update Customer record in Customer Data Store FOR all Customers in Customer Data Store, do Generate a new line in the Customer Report Add Customer’s Total Sales to Report Total CASE If Income < 10,000: Marginal tax If Income < 20,000: Marginal tax If Income < 30,000: Marginal tax If Income < 40,000: Marginal tax ELSE Marginal tax rate = 38% ENDCASE rate rate rate rate = = = = 10% 20% 31% 35%

If Statement

For Statement

Case Statement

Software Engineering, 

 Slide  181