Transcript Project management

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
What is software?
Software is
1. Instructions(computer programs) that when executed provide
desired function and performance,
2. Data structures that enable the programs to adequately
manipulate information and
3. 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 fourth era :
•Powerful desktop systems
•Object-oriented technologies
•Expert systems
•Artificial neural networks
•Parallel computing
•Network computers
Software Engineering,
Slide 6
The third era :
•Distributed systems
•Embedded “intelligence”
•Low cost hardware
•Customer impact
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 - 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?


The software should deliver the required functionality and
performance to the user and should be maintainable,
dependable and usable
Maintainability
•

Dependability
•

Software must be trustworthy
Efficiency
•

Software must evolve to meet changing needs
Software should not make wasteful use of system resources
Usability
•
Software must be usable by the users for which it was designed
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



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?



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

Getting started with software engineering
Software Engineering,
Slide 15
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
Topics covered

FAQs about software engineering
Software Engineering,
Slide 17
(IEEE) Software Engineering is
1. The application of a systematic ,disciplined , quantifiable
approach to the development, operation , and maintenance
of software ; that is the application of engineering to
software ;
2. 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?


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?


Structured approaches to software development which include
system models, notations, rules, design advice and process
guidance
Model descriptions
•

Rules
•

Constraints applied to system models
Recommendations
•

Descriptions of graphical models which should be produced
Advice on good design practice
Process guidance
•
What activities to follow
Software Engineering,
Slide 20
What are the key challenges facing
software engineering?


Coping with legacy systems, coping with increasing
diversity and coping with demands for reduced delivery
times
Legacy systems
•

Heterogeneity
•

Old, valuable systems must be maintained and updated
Systems are distributed and include a mix of hardware and
software
Delivery
•
There is increasing pressure for faster delivery of software
Software Engineering,
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
What is the difference between software
engineering and system engineering?


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?


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




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.
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 :
1. Assumptions
2. Simplifications
3. Limitations
4. Constraints
5. 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

Coherent sets of activities for specifying,
designing, implementing and testing
software systems
Software Engineering,
Slide 52
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, 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?


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
Generic process models
•
•
•
•
Waterfall
Evolutionary development
Formal transformation
Integration from reusable components
Software Engineering,
Slide 55
Generic software process models



System Development Life Cycle Model
Prototyping Model
The waterfall model
•

Evolutionary development
•

Specification and development are interleaved
Formal systems development
•

Separate and distinct phases of specification and development
A mathematical system model is formally transformed to an
implementation
Reuse-based development
•
The system is assembled from existing components
Software Engineering,
Slide 56
Classical System Development Life Cycle :
The System development life cycle method consists of the
following activities :
1. Preliminary investigation
2. Determination of system requirements
3. Design of system
4. Development of software
5. System testing
6. 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 :
1. Request classification
2. Feasibility study
3. 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 :
1. Technical Feasibility
2. Economic Feasibility
3. 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 :
1. What is being done ?
2. How is it being done ?
3. How frequently does it occur ?
4. How great is the volume of transactions or decisions ?
5. How well is the task being performed?
6. Does the problem exist?
7. If the problem exists , how serious it is ?
8. 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

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




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



Prototyping in the software process
Prototyping techniques
User interface prototyping
Software Engineering,
Slide 71
System prototyping



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

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
Prototyping can be considered as a risk reduction activity
which reduces requirements risks
Software Engineering,
Slide 73
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
Prototyping benefits





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

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 system is then developed using some
other development process
Software Engineering,
Slide 76
Prototyping objectives


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
Delivered
system
Throw-away
Prototyping
Executable Prototype +
System Specification
Outline
Requirements
Software Engineering,
Slide 78
Evolutionary prototyping



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 :
1. Identify the user’s known information requirements and
features needed in the system.
2. Develop a working prototype.
3. Use the prototype , noting needed enhancements and
changes.These expand the list of known system
requirements.
4. Revise the prototype based in information gained through
user experience.
5. 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 :
1.
The prototype is redeveloped . This alternative may mean complete
reprogramming from scratch.
2.
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.
3.
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.
4.
Another prototyping series begun.The information gained through the
current experience may suggest an entirely different approach to
contrasting features.
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






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
Evolutionary Software Process Models :
1. The Incremental Model
2. The Spiral Model
3. The Component assembly model
4. 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



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
Assign requirements
to increments
Develop system
increment
Valida te
increment
Design system
architecture
Integrate
increment
Valida te
system
Final
system
System incomplete
Software Engineering,
Slide 93
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.
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
Evaluate alternatives
identify, resolve risks
Risk
analysis
Risk
analysis
REVIEW
Requirements plan
Life-cycle plan
Development
plan
Plan next phase
Software Engineering,
Integration
and test plan
Slide 98
Prototype 3
Prototype 2
Risk
a nayl sis Prototype 1
Operational
protoype
Simulations, models, benchmarks
Concept of
Operation
S/W
requirements
Requirement
validation
Product
design
Detailed
design
Code
Unit test
Design
V&V
Integr ation
test
Acceptance
test
Develop, verify
Service
next-level product
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

Objective setting
•

Risk assessment and reduction
•

Risks are assessed and activities put in place to reduce the key
risks
Development and validation
•

Specific objectives for the phase are identified
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,
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



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


The process of converting the system specification into
an executable system
Software design
•

Implementation
•

Design a software structure that realises the specification
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
testing
Software Engineering,
Integration testing
Slide 109
User
testing
Testing stages

Unit testing
•

Module testing
•

Modules are integrated into sub-systems and tested. The focus
here should be on interface testing
System testing
•

Related collections of dependent components are tested
Sub-system testing
•

Individual components are tested
Testing of the system as a whole. Testing of emergent properties
Acceptance testing
•
Testing with customer data to check that it is acceptable
Software Engineering,
Slide 110
Testing phases
Requir ements
specification
System
specification
System
integration
test plan
Acceptance
test plan
Service
System
design
Acceptance
test
Software Engineering,
Slide 111
Detailed
design
Sub-system
integration
test plan
System
integration test
Sub-system
integration test
Module and
unit code
and tess
Software evolution



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 :
1. Diagramming tools
2. An information repository
3. Interface generators
4. Code generators and
5. 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)


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

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


Classification helps us understand the different types of
CASE tools and their support for process activities
Functional perspective
•

Process perspective
•

Tools are classified according to their specific function
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
CASE integration

Tools
•

Workbenches
•

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
Environments
•
Support all or a substantial part of an entire software process.
Normally include several integrated workbenches
Software Engineering,
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, 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





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

Descriptions and specifications of a system
Software Engineering,
Slide 127
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,
Slide 128
Topics covered




Functional and non-functional requirements
User requirements
System requirements
The software requirements document
Software Engineering,
Slide 129
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 130
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
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

User requirements
•

System 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
Software specification
•
A detailed software description which can serve as a basis for a
design or implementation. Written for developers
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 requirements
System end-users
Client engineers
System architects
Software developers
Software design
specification
Software Engineering,
Slide 134
Client engineers (perhaps)
System architects
Software developers
Functional and non-functional
requirements

Functional requirements
•

Non-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.
Domain requirements
•
Requirements that come from the application domain of the
system and that reflect characteristics of that domain
Software Engineering,
Slide 135
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,
Slide 136
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.
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.
Software Engineering,
Slide 137
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 - 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


In principle requirements should be both complete and
consistent
Complete
•

Consistent
•

They should include descriptions of all facilities required
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,
Slide 139
Non-functional requirements



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

Product requirements
•

Organisational 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.
External requirements
•
Requirements which arise from factors which are external to the
system and its development process e.g. interoperability
requirements, legislative requirements, etc.
Software Engineering,
Slide 141
Non-functional requirement
types
Non-functional
requir ements
Product
requir ements
Ef ficiency
requir ements
Reliability
requir ements
Usability
requirements
Performance
requirements
Or ganizational
requir ements
Portability
requirements
Delivery
requirements
Space
requir ements
Software Engineering,
Slide 142
External
requirements
Interoperability
requirements
Implementation
requir ements
Ethical
requirements
Standards
requirements
Legislative
requirements
Privacy
requirements
Safety
requirements
Goals and requirements


Non-functional requirements may be very difficult to state
precisely and imprecise requirements may be difficult to
verify.
Goal
•

Verifiable non-functional requirement
•

A general intention of the user such as ease of use
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,
Slide 143
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.
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,
the average number of errors made by experienced users shall
not exceed two per day.
Software Engineering,
Slide 144
Requirements measures
Pro perty
Speed
Size
Eas e of u se
Rel iabi li ty
Rob u st ness
P ortabi li ty
Software Engineering,
Meas ure
P ro cess ed t rans acti o ns /s econ d
User/ Event res po n se ti me
Screen refresh t ime
K By tes
Nu mb er o f RAM ch ip s
Train in g time
Nu mb er o f h elp frames
Mean ti me t o failu re
P ro b ab il ity o f u n av ailab ili ty
Rat e of failu re o ccu rren ce
Av ai lab i lit y
Time to rest art aft er failu re
P ercent ag e o f event s caus in g fail ure
P ro b ab il ity o f d ata co rru pt io n on fail ure
P ercent ag e o f targ et d ep end ent st at ement s
Nu mb er o f t arget sy st ems
Slide 145
Requirements interaction


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



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

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 148
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,
tables and diagrams
Software Engineering,
Slide 149
Problems with natural
language

Lack of clarity
•

Requirements confusion
•

Precision is difficult without making the document difficult to
read
Functional and non-functional requirements tend to be mixedup
Requirements amalgamation
•
Several different requirements may be expressed together
Software Engineering,
Slide 150
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
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, 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



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






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









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 :
1. What data to input
2. What medium to use
3. How the data should be arranged or coded
4. The dialogue to guide users in providing input
5. Data items and transactions needing validation to
detect errors
6. 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
1. The interview
2. Questionnaire
3. Record inspections (on-site review)
4. 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:
(i)interviewer fails to understand what
users say,
(ii) 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

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
Example
Action Statement
Profits = Revenues - 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, do
Generate a new line in the Customer Report
Add Customer’s Total Sales to Report Total
Case Statement
Software Engineering,
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
Slide 181
rate
rate
rate
rate
=
=
=
=
10%
20%
31%
35%