You are on page 1of 181

Introduction

Software Engineering,   Slide  1

Software engineering
●The economies of ALL developed nations are
dependent on software
More and more systems are software controlled

●Software engineering is concerned with theories, methods
and tools for professional software development
●Software engineering expenditure represents a
significant fraction of GNP in all developed countries

Software Engineering,   Slide  2

FAQs about software
engineering
● 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

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

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

● 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 .   Slide  8 .developed for a single customer according to their specification Software Engineering.developed to be sold to a range of different customers • Bespoke (custom) .

 Software is expressive. Software  is cheap. Software is huge. All computable functions may  be expressed in software. An operating system may  consist of millions of lines of code. Software is complex.   Slide  9 .The Nature of Software Software is flexible. Complex event driven systems may be  expressed in software.  Software Engineering. 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 an executable specification of a  computation.

   Slide  10 . dependable and usable ● Maintainability • Software must evolve to meet changing needs ● Dependability • Software must be trustworthy ● Efficiency • Software should not make wasteful use of system resources ● Usability • Software must be usable by the users for which it was designed Software Engineering.What are the attributes of good software? ● The software should deliver the required functionality and performance to the user and should be maintainable.

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

   Slide  12 . maintenance costs may be several times development costs ● Software engineering is concerned with cost-effective software development Software Engineering. For systems with a long life.Software costs ● 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.

 Software is communication. The  changing requirements and ease of modification permits the  maintenance phase to dominate a software product's life cycle.e. and the coder. Software Engineering. Software is never finished. Software must be  readable in order to be evolvable. i. the software  architect..   Slide  13 . development cost is everything. Communication with a  machine but also communication between the client.  the maintenance phase consists of on going design and  implementation cycles.Manufacturing cost is zero. 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.  the first copy is the engineering prototype. the software engineer. Software is easily modified. the production  prototype and the finished product. Thus.

   Slide  14 . For custom software.What are the costs of software engineering? ● Roughly 60% of costs are development costs. 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. 40% are testing costs.

   Slide  15 .Introduction ● Getting started with software engineering Software Engineering.

Objectives ● To introduce software engineering and to explain its importance ● To set out the answers to key questions about software engineering Software Engineering.   Slide  16 .

   Slide  17 .Topics covered ● FAQs about software engineering Software Engineering.

that is the application of engineering to software . 3. operation .(IEEE) Software Engineering is 2. The application of a systematic . and maintenance of software . quantifiable approach to the development. 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.disciplined . The study of approaches as in 1.   Slide  18 .

   Slide  19 . the development constraints and the resources available Software Engineering.What is software engineering? ● 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.

notations.What are software engineering methods? ● Structured approaches to software development which include system models.   Slide  20 . design advice and process guidance ● Model descriptions • Descriptions of graphical models which should be produced ● Rules • Constraints applied to system models ● Recommendations • Advice on good design practice ● Process guidance • What activities to follow Software Engineering. rules.

coping with increasing diversity and coping with demands for reduced delivery times ● Legacy systems • Old. valuable systems must be maintained and updated ● Heterogeneity • Systems are distributed and include a mix of hardware and software ● Delivery • There is increasing pressure for faster delivery of software Software Engineering.What are the key challenges facing software engineering? ● Coping with legacy systems.   Slide  21 .

What is the difference between software engineering and computer science? ● 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 .

software and process engineering.What is the difference between software engineering and system engineering? ● System engineering is concerned with all aspects of computer-based systems development including hardware.   Slide  23 . architectural design. integration and deployment Software Engineering. Software engineering is part of this process ● System engineers are involved in system specification.

changing the software in response to changing demands Software Engineering.what the system should do and its development constraints • Development .production of the software system • Validation .What is a software process? ● A set of activities whose goal is the development or evolution of software ● Generic activities in all software processes are: • Specification .   Slide  24 .checking that the software is what the customer wants • Evolution .

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

and management of technical(or social) entities . construction . design. verification .   Slide  26 .A generic view of software engineering : Engineering is the analysis . 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. Regardless of the entity that is to be engineered .

Software Engineering. When corrections . and enhancements are requested by users of the entity .   Slide  27 . adaptations .•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.

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

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

   Slide  30 .System Engineering Software Engineering.

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

Software Engineering.   Slide  32 .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 .

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

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

Systems Requirement Software Engineering.   Slide  35 .

at the same time we are required to build up a successful system in which the system. Software Engineering. Information system is a system that collects information.   Slide  36 .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. manages them and creates information products for its users. however. information expert’s view point and user’s one. information experts and end users share the same view point. These points of view often conflict with one another. we can classify them into groups: view point of the system that will be developed.

   Slide  37 . these requirements should be regularly checked for its suitability with the general strategies. Supporting decision maker: Together with hands-on experience. information system plays an important role in supporting decision making process. during the system development process. Competition edge: The more competitive the environment.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. the more demand for better systems. Software Engineering. knowledge and anticipating ability. Therefore.

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

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

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

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

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

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

System Modeling Software Engineering.   Slide  44 .

•Represent all linkages (including output) that will enable the engineer to better understand the view.   Slide  45 . Whether the focus is on the real world view or the detailed view . •Represent the behavior of the process and assumptions on which the behavior is based . •Explicitly define both exogenous and endogenous input to the model. the engineer creates models that : •Define the process that serve the needs of the view under consideration . Software Engineering.System Modeling is an important element of the system engineering process .

Preferences Software Engineering. the engineer should consider a number of restraining factors : 3.   Slide  46 .To construct a system model . Constraints 7. Limitations 6. Simplifications 5. Assumptions 4.

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

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

telecommunication links . .The infrastructure encompasses the hardware and software that are used to support the applications and data . storage technologies . networks .g. client/server) that has been designed to implement Software Engineering. characteristic . quality .This includes computers .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 . and the architecture (e. or descriptor of the data that are being described. operating systems .. A data object contains a set of attributes that define some aspect .   Slide  49 these technologies. 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 .

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

   Slide  51 . Software Processes (Process Models) Software Engineering.

Software Processes ● Coherent sets of activities for specifying. designing.   Slide  52 . implementing and testing software systems Software Engineering.

   Slide  53 .Objectives ● 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. testing and evolution ● To introduce CASE technology to support software process activities Software Engineering. software development.

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

sequence of activities • Data-flow perspective .who does what ● Generic process models • Waterfall • Evolutionary development • Formal transformation • Integration from reusable components Software Engineering.   Slide  55 .information flow • Role/action perspective . presented from a specific perspective ● Examples of process perspectives are • Workflow perspective .What is a software process model? ● A simplified representation of a software process.

   Slide  56 .Generic software process models ● System Development Life Cycle Model ● Prototyping Model ● The waterfall model • Separate and distinct phases of specification and development ● Evolutionary development • Specification and development are interleaved ● Formal systems development • A mathematical system model is formally transformed to an implementation ● Reuse-based development • The system is assembled from existing components Software Engineering.

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

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

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

existing software technology . Software Engineering. 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.   Slide  60 . and available personnel ? If new technology is required .Technical Feasibility : Can the work of the project be done with current equipment .

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

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

I. In many organizations. Software Engineering.e. 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.   Slide  65 . and the results examined.Systems Testing :During systems testing.. the system is used experimentally to ensure that the software does not fail. testing is performed by persons other than those who wrote the original programs to ensure more complete and unbiased testing and more reliable software.It is preferable to discover any surprises before the organization implements the system and depends on it. Special test data are input for processing . it will run according to its specifications and in the way users expect .

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

   Slide  67 . Software Prototyping Software Engineering.

Software Prototyping ● Rapid software development to validate requirements Software Engineering.   Slide  68 .

   Slide  69 .Prototyping process Establish Define Develop Evaluate prototype prototype prototype prototype objectives functionality Prototyping Outline Executable Evaluation plan definition prototype report Software Engineering.

high- level language development.Objectives ● 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 .   Slide  70 . database programming and component reuse ● To explain the need for user interface prototyping Software Engineering.

   Slide  71 .Topics covered ● Prototyping in the software process ● Prototyping techniques ● User interface prototyping Software Engineering.

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

Uses of system prototypes ● 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.   Slide  73 . The prototype can reveal errors and omissions in the requirements ● Prototyping can be considered as a risk reduction activity which reduces requirements risks Software Engineering.

Prototyping benefits ● 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 .

   Slide  75 .Prototyping benefits ● Improved system usability ● Closer match to the system needed ● Improved design quality ● Improved maintainability ● Reduced overall development effort Software Engineering.

   Slide  76 . The system is then developed using some other development process Software Engineering.Prototyping in the software process ● Evolutionary prototyping • An approach to system development where an initial prototype is produced and refined through a number of stages to the final system ● Throw-away prototyping • A prototype which is usually a practical implementation of the system is produced to help discover requirements problems and then discarded.

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

   Slide  78 .Approaches to prototyping Evolutionary Delivered prototyping system Outline Requirements Throw­away Executable Prototype + Prototyping System Specification Software Engineering.

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

Software Engineering. perform calculations. produces printed or displayed information . or performs meaningful activities.Systems Prototype Method : This method involves the user more directly in the analysis and design experience than SDLC method.   Slide  80 .an original model. A prototype is a working system that is developed to test ideas and assumptions about the new system. Like any computer- based system . Prototyping is very effective under the correct circumstances . It consists of working software that accepts input.It is the first version or iteration of an information system .

This can be effectively done only if the data are real and the situations live. The prototype is designed to be easily changed. Software Engineering.The design and the information produced by the system are evaluated by users. The prototype is actually a pilot test model. Changes are expected as the system is used. the design evolves through use.   Slide  81 . The process is repeated as many times as necessary to reveal essential design requirements.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.

•Alternative versions of the system will evolve through experience and additional development and refinement of its features.The prototype is most useful under following conditions : • No system with the characteristics of the one proposed has yet been constructed by the developers. 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 . •The system user(s) will participate in the development process. •The essential features of the system are only partially known.   Slide  82 . Software Engineering.

Experience and use produce more meaningful comment than analysis of charts and narrative proposals .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.   Slide  83 . Software Engineering.

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

The project is abandoned . they determine how to meet the requirements they have identified. Each alternative is viewed as a successful result of prototyping. Performance efficiency and methods for user interaction may be sufficient to allow the system to be used as is. Another prototyping series begun. The prototype is implemented as the complete system. This alternative may mean complete reprogramming from scratch. 3.   Slide  85 . Software Engineering.The information gained through the current experience may suggest an entirely different approach to contrasting features.When both user and analyst decide that sufficient information has been collected from the prototyping process. 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. The prototype is redeveloped . 5. 4. Usually one of the following four alternatives is selected : 2.

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 ● 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 ● 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 ● 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 ● Throw-away prototyping • Objective is to understand the system requirements. Should start with poorly understood requirements Software Engineering.   Slide  89 .

The concurrent development model Software Engineering. The Component assembly model 6.Evolutionary Software Process Models : 3.   Slide  90 . The Spiral Model 5. The Incremental Model 4.

a plan is developed for next increment . the first increment is often a core product . but many supplementary features (some known.The core product is used by the customer (or undergoes detailed review). When an incremental model is used .This process is repeated following the delivery of each increment .   Slide  91 .others unknown) remain undelivered.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 .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 . until the complete product is produced.As a result of use and/or evaluation . Software Engineering. basic requirements are addressed . That is.

   Slide  92 . 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.Incremental development ● Rather than deliver the system as a single delivery. the requirements are frozen though requirements for later increments can continue to evolve Software Engineering.

   Slide  93 .Incremental development Define outline Assign requirements Design system  requirements       to increments architecture Develop system Valida te Integrate Valida te increment increment increment system Final system System incomplete Software Engineering.

Incremental development advantages ● 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 ● 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 ● 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.loops in the spiral are chosen depending on what is required ● Risks are explicitly assessed and resolved throughout the process Software Engineering. ● No fixed phases such as specification or design .   Slide  96 .

During later iterations .It provides the potential for rapid development of incremental versions of the software .   Slide  97 . the incremental release might be a paper model or prototype. Software Engineering.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 . software is developed in a series of incremental releases .During early iterations . increasingly more complete versions of the engineered versions are produced.In the spiral model .

 benchmarks Life­cycle plan Concept of Operation S/W requirements Product design Detailed Requirement design Development plan validation Code Design Unit test Integration and test plan V&V Integr ation Plan next phase test Acceptance Service test Develop.Spiral model of the software process Determine objectives Evaluate alternatives alternatives and identify.   Slide  98 . verify next­level product Software Engineering. models. resolve risks constraints Risk analysis Risk analysis Risk analysis Opera­ Prototype 3 tional Prototype 2 protoype Risk REVIEW analy sis Proto­ type 1 Requirements plan Simulations.

The spiral model is divided into a number of framework activities . •Customer communications – tasks required to establish effective communications between developer and customer. install and provide use support. •Construction and release – tasks required to construct . •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. •Engineering – tasks required to build one or more representations of the application.   Slide  99 . Software Engineering. •Risk analysis –tasks required to access both technical and management risks. •Planning –tasks required to define resources . timeliness and other project related information. test . also called task regions .

   Slide  100 .Spiral model sectors ● Objective setting • Specific objectives for the phase are identified ● Risk assessment and reduction • Risks are assessed and activities put in place to reduce the key risks ● Development and validation • A development model for the system is chosen which can be any of the generic models ● Planning • The project is reviewed and the next phase of the spiral is planned Software Engineering.

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

Component and application assembly ● 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 .

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.The Concurrent Development Model : The concurrent process model can be represented schematically as a series of major technical activities .   Slide  103 . tasks .

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 Model : Rapid Action Development is a linear sequential software development process model that emphasizes an extremely short development cycle. 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 .

   Slide  105 . Automated tools are used to facilitate construction of software.•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 . •Application generation :The RAD process works to reuse existing program components(when possible) to create reusable components (when necessary). 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. Software Engineering.

•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
● The process of converting the system specification into
an executable system
● Software design
• Design a software structure that realises the specification
● Implementation
• Translate this structure into an executable program
● The activities of design and implementation are closely
related and may be inter-leaved

Software Engineering,   Slide  107

Software validation
● 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 Integration testing User
testing testing
Software Engineering,   Slide  109

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

   Slide  111 .Testing phases Requir ements System System Detailed specification specification design design System Sub­system Module and Acceptance integration integration unit code test plan test plan test plan and tess Acceptance System Sub­system Service test integration test integration test Software Engineering.

● As requirements change through changing business circumstances.Software evolution ● Software is inherently flexible and can change. 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 .

Interface generators 6. Diagramming tools 4. Management tools Software Engineering. Code generators and 7.CASE tools generally include five components : 3.   Slide  114 . An information repository 5.

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

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

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

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

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

Automated process support (CASE) ● 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 does not really support these Software Engineering.   Slide  121 . much time is spent in team interactions.this is not readily automatable • Software engineering is a team activity and. for large projects.Case technology ● 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 .

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 Software Engineering.   Slide  122 .

Normally include several integrated workbenches Software Engineering. ● Workbenches • Support a process phase such as specification or design.CASE integration ● Tools • Support individual process tasks such as design consistency checking. text editing. etc. Normally include a number of integrated tools ● Environments • Support all or a substantial part of an entire software process.   Slide  123 .

Key points ● 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.   Slide  124 . 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.

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 the system after it is in use ● CASE technology supports software process activities Software Engineering.   Slide  125 .

Software Requirements Software Engineering.   Slide  126 .

   Slide  127 .Software Requirements ● Descriptions and specifications of a system Software Engineering.

   Slide  128 .Objectives ● 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.

Topics covered ● Functional and non-functional requirements ● User requirements ● System requirements ● The software requirements document Software Engineering.   Slide  129 .

   Slide  130 .Requirements engineering ● 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  131 .therefore must be open to interpretation • May be the basis for the contract itself .What is a requirement? ● 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 defined in detail • Both these statements may be called requirements Software Engineering.

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

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

   Slide  134 .Requirements readers Client managers System end­users User requirements Client engineers Contractor managers System architects System end­users Client engineers System requirements System architects Software developers Client engineers (perhaps) Software design System architects specification Software developers Software Engineering.

etc.   Slide  135 . standards. constraints on the development process. ● Domain requirements • Requirements that come from the application domain of the system and that reflect characteristics of that domain Software Engineering.Functional and non-functional requirements ● Functional requirements • Statements of services the system should provide. ● Non-functional requirements • constraints on the services or functions offered by the system such as timing constraints. how the system should react to particular inputs and how the system should behave in particular situations.

   Slide  136 .Functional requirements ● 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.

● The system shall provide appropriate viewers for the user to read documents in the document store.   Slide  137 . Software Engineering.Examples of functional requirements ● The user shall be able to search either all of the initial set of databases or select a subset from it. ● 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.

Requirements imprecision ● 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 .   Slide  138 .Provide a text viewer that shows the contents of the document Software Engineering.special purpose viewer for each different document type • Developer interpretation .

   Slide  139 .Requirements completeness and consistency ● In principle requirements should be both complete and consistent ● Complete • They should include descriptions of all facilities required ● Consistent • There should be no conflicts or contradictions in the descriptions of the system facilities ● In practice. it is impossible to produce a complete and consistent requirements document Software Engineering.

reliability. response time and storage requirements.   Slide  140 . the system is useless Software Engineering. etc.g. Constraints are I/O device capability. system representations. ● 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.Non-functional requirements ● Define system properties and constraints e.

execution speed.Non-functional classifications ● Product requirements • Requirements which specify that the delivered product must behave in a particular way e. etc. etc.   Slide  141 . interoperability requirements. process standards used. implementation requirements. reliability.g.g.g. Software Engineering. etc. ● Organisational requirements • Requirements which are a consequence of organisational policies and procedures e. ● External requirements • Requirements which arise from factors which are external to the system and its development process e. legislative requirements.

Non-functional requirement types Non­functional requir ements Product Or ganizational External requir ements requir ements requirements Ef ficiency Reliability Portability Interoperability Ethical requir ements requir ements requirements requirements requirements Usability Delivery Implementation Standards Legislative requirements requirements requir ements requirements requirements Performance Space Privacy Safety requirements requir ements requirements requirements Software Engineering.   Slide  142 .

   Slide  143 . ● Goal • A general intention of the user such as ease of use ● Verifiable non-functional requirement • A statement using some measure that can be objectively tested ● Goals are helpful to developers as they convey the intentions of the system users Software Engineering.Goals and requirements ● Non-functional requirements may be very difficult to state precisely and imprecise requirements may be difficult to verify.

   Slide  144 . ● A verifiable non-functional requirement • Experienced controllers shall be able to use all the system functions after a total of two hours training. After this training.Examples ● 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. Software Engineering. the average number of errors made by experienced users shall not exceed two per day.

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

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

Domain requirements ● Derived from the application domain and describe system characterisics and features that reflect the domain ● May be new functional requirements. the system may be unworkable Software Engineering.   Slide  147 . constraints on existing requirements or define specific computations ● If domain requirements are not satisfied.

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

   Slide  149 . tables and diagrams Software Engineering.User requirements ● 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.

   Slide  150 .Problems with natural language ● Lack of clarity • Precision is difficult without making the document difficult to read ● Requirements confusion • Functional and non-functional requirements tend to be mixed- up ● Requirements amalgamation • Several different requirements may be expressed together Software Engineering.

Requirement problems ● 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 ● 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 .

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

The requirements document ● 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.   Slide  153 . As far as possible. it should set of WHAT the system should do rather than HOW it should do it Software Engineering.

Requirements document requirements ● 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.   Slide  154 . predict changes ● Characterise responses to unexpected events Software Engineering.

   Slide  155 .Requirements document structure ● Introduction ● Glossary ● User requirements definition ● System architecture ● System requirements specification ● System models ● System evolution ● Appendices ● Index Software Engineering.

User-computer interface design Software Engineering.   Slide  156 .

Its features influence the effectiveness of the user of the system .What is an Interface ? An interface is the common boundary between the user and the computer system application. as well as the frequency of mistakes and errors when entering data or instructions.the point where the computer and the individual interact . Software Engineering.   Slide  157 .

or voice.   Slide  158 . light pen . scanner . Software Engineering.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. touch screen .

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

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

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

Software Engineering.   Slide  162 . the following tasks must be accomplished : •Determine what information to present •Decide whether to display . 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.When designing the output . print .

Menu – Driven Dialogue : Since online systems provide several input and processing options to users. Software Engineering. a method is needed to show users .. Dialogues that use this method of interaction are said to be menu driven.   Slide  163 .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 . Menu serves this purpose . a method is needed to show users the available alternatives.

   Slide  164 . Investigation Methods Software Engineering.

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

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.Most of the difficulties one can meet in system analysis result from the survey process. and it requires great effort so as to decide what information to collect and how to collect it. Software Engineering. all information reflecting the current situation have to be collected. In fact.   Slide  166 .

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

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

   Slide  169 .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. Software Engineering. Moreover. which will affect your survey’s quality. those you’re looking at may feel uncomfortable and may behave unusually.

Software Engineering.Unofficial observation: In order to get an overview of an organization.   Slide  170 . 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. take a look at its pile of paper and document. unreasonable timing and positive reflection of a good working environment. interruption of work. Researching through document is the final good method to get important information...

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

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

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

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

It is also a method of showing the relationship of each condition and its permissible actions.The right side of the tree lists the actions to be taken depending on sequence of conditions that is followed. Following each decision point is the next set of decisions to be considered . is the starting point of the decision sequence . which second .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 . Progression from left to right along a particular branch is the result of making a series of decisions . The particular branch followed depends on the conditions that exist and the decision to be made . and so on. The root of the tree .   Slide  175 . Software Engineering. on the left of the diagram . 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 .

First of all .Using Decision Trees : Developing decision trees is beneficial to analysts in two ways . Software Engineering. Decision trees also force analysts to consider the sequence of decisions.   Slide  176 . whether it depends on quantitative or non quantitative variables. 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.

Decision Trees ● Graphical way of depicting if-then-else logic Software Engineering.   Slide  177 .

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

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

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

000: Marginal tax rate = 10% If Income < 20.000: Marginal tax rate = 35% ELSE Marginal tax rate = 38% ENDCASE Software Engineering.000: Marginal tax rate = 20% If Income < 30. do Generate a new line in the Customer Report Add Customer’s Total Sales to Report Total Case Statement CASE If Income < 10.Expenses Generate Inventory Report Add Product record to Product Data Store If Statement 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 Statement FOR all Customers in Customer Data Store.000: Marginal tax rate = 31% If Income < 40.Structured English Common Statements Example Action Statement Profits = Revenues .   Slide  181 .