IT2401 Fundamentals of Software Engineering fseict'cmb'ac'lk

1
PREPARING FOR THE
IT2401 Fundamentals ofSoftware Engineering
fse_at_ict.cmb.ac.lk
2
A Use-case Diagram
Use-cases are a scenario-based technique for
requirements elicitation which were first
introduced in the Objectory methods (Jacobson et
at 1993).
3
Non-functional Requirements
? Define system properties and constraints Eg
reliability, performance, interface,
security, storage requirements. ?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.
4
Requirements verifiability Requirements
should be written so that they can be
objectively verified. The problem with this
requirement is its use of vague terms such as
errors should be minimised Experienced
controllers should 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 an experienced users
should not exceed two per day
5
Non-functional Requirements measures
6
Software Requirements Document - IEEE standard

• Introduction
• 1.1 Purpose of the requirements document
• 1.2 Scope of the product
• 1.3 Definitions, acronyms and
  abbreviations
• 1.4 References
• 1.5 Overview of the remainder of the
  document
• 2. General Description
• 2.1 Product perspective
• 2.2 Product functions
• 2.3 User characteristics
• 2.4 General constraints
• 2.5 Assumptions and dependencies
• Specific requirements
• All functional and non-functional
  requirements
• System models (eg. DFD, ERD, Use-Case,
  Class, Sequence diagrams)
• External Interfaces, Performance, database
  requirements, design constraints
• Security, quality characteristics
• 4. Appendices

7

• Requirement Evolution
• Over the time, The systems environment and the
  business objectives will almost certainly
  changed. The requirements must therefore evolve
  to reflect this.
• From an evolution perspective, requirements fall
  into two classes
• Enduring requirements These are relatively
  stable requirements which derive from the core
  activity of the organisation and which relate
  directly to the domain of the system.
• Volatile requirements These are requirements
  which are likely to change during the system
  development or after the system has been

8
Requirements Evolution
Initial Understanding of problem
Changed Understanding of the problem
Initial Requirements
Changed requirements
Time
9

• Requirements Validation
• Requirements validation is concerned with
  showing that the requirements actually define the
  system which the customer wants.
• Requirements validation is important because
  errors in a requirements document can lead to
  extensive rework costs when they are subsequently
  discovered during development or after the system
  is in service.

10

• Requirements Validation Checks
• Validity checks - Systems have diverse users
  with different needs and any set of requirements
  is inevitably a compromise across the user
  community.
• Consistency checks - Requirements in a document
  should not conflict.
• Completeness checks The requirements document
  should include requirements which define all
  functions and constraints intended by the system
  user.
• Realism checks - Using knowledge of existing
  technology, the requirements should be checked to
  ensure that they can actually be implemented.
• Verifiability - The requirements should be
  given in verifiable manner (eg Using
  quantifiable measures) to reduce the potential
  for dispute between customer and developer.

11
Requirements Validation - Techniques

• Requirements Reviews - The requirements are
  analalysed systematically by a team of reviewers.
  
• Prototyping - In this approach to validation,
  an executable model of the system is demonstrated
  to end-users and customers. They can check
  whether the requirements satisfy their needs.
• Test-case generation - Requirements should
  ideally be testable. If a test is difficult or
  impossible to design, this usually means that the
  requirements will be difficult to implement and
  should be reconsider.
• Automated consistency analysis If the
  requirements are expressed as a system model in a
  structured or formal notation than CASE toolsmay
  be used to check the consistency of the model.

12
1.
During the requirement analysis stage, which of
the following requirements should be
identified? (a) Functional requirements
(b) Interface requirements (c)
Programming language requirement (d)
Person resource requirements (e)
Performance requirements



13
2.
Decision tables are used in process
specification. Identify the correct decision
table for the functionality of the following
order processing operation. If the customer has
credit facilities accept the order. Otherwise if
the customer is a prompt payer accept the order.
New customers are referred to the credit manager
for a decision.
14
(a)
Y N N N Y N N N Y
Credit facilities Prompt payer New customer
Accept order Reject order Refer to credit manager
X X X

15

• (b)

Y N N N Y N N N Y
Credit facilities Prompt payer New customer
Accept order Reject order Refer to credit manager
X X X

16

• (c)

Y N N N Y N N N Y
Credit facilities Prompt payer New customer
Accept order Reject order Refer to credit manager
X X X

17

• (d)

Y N N N Y N N N Y
Credit facilities Prompt payer New customer
Accept order Reject order Refer to credit manager
X X
X
18

• (e)

Y N N N Y N N N Y
Credit facilities Prompt payer New customer
Accept order Reject order Refer to credit manager
X X
X
19
5. Requirement validation is an essential
process which should be carried out before
proceeding to Design. The aspects of requirements
which must be checked during this process are
(a) validity, reusability, complexity and
accuracy (b) portability, flexibility,
completeness and accuracy (c) validity,
consistency, completeness and realism (d)
complexity, maintainability, correctness and
realism (e) validity, user friendliness,
accuracy and completeness

20
6.
Which of the following are true with regard to
the requirement validation (a) Prototyping
can be used to validate requirements (b)
Requirement validation should be carried out
after the first requirement
specification has been carried out.
(c) Requirement validation is a process use
to make sure that the correct
methods are used in the development
of the system.


21
Continued (d) Requirement validation is
done by the developer only. (e)
Requirement validation should make
sure the completeness of requirements.

22

• 10. Identify from among the following options,
  the technique(s) used in the analysis stage.
• Dataflow Diagrams
• Entity relationship diagram
• Structure charts
• Use case diagrams
• Document flow diagrams

23

• 12. A software requirements definition is an
  abstract description of the srvices which the
  system should provide, and the constraints under
  which the system must operate. Which of the
  following statements is/are associated with a
  requirement definition?
• Customers should be understand it easily
• It should accurately reflect what the customers
  wants.
• To reduce ambiguity, it may be written in a
  structured language of some kind.
• It must be presented with the system model
  developed during requirements analysis.
• It must include all necessary information about
  what the system must do and all constraints on
  its operations.

24
Software Engineering Software Process

• Learning Outcomes
• ? Appreciate the need for a defined software
  process
• Be able to describe in detail the main software
  process models
• Be able to compare software process models and
  choose
• between them

25
What is a Software Process?

• a process is important because it imposes
  consistency and structure on a set of activities
• it guides our actions by allowing us to
  examine,understand, control and improve the
  activities that comprise the process
• the process of building a product is sometime
  called a lifecycle because it describes the life
  of that product from conception through to its
  implementation,delivery,use and maintenance
• a set of ordered tasks involving
  activities,constraints and resources that produce
  a software system

26
Software process models

• Prototyping models
• Evolutionary models
• The spiral model
• Formal development
• Waterfall model
• Incremental development
• Rapid Application Development

27
The Waterfall model Separate and distinct phases
of specification and development A linear
sequential model
28
Waterfall model
29
The Waterfall Model Software Requirement Analysis
and Specification The systems services,
constraints and goals are established with the
consultation with the users. This would include
the understanding of the information domain for
the software, functionality, behaviour,
performance, interface, security and exceptional
requirements. This requirements are then
specified in a manner which is understandable by
both users and the development staff.
30
Software design The design process translates
requirements into a representation of the
software that can be implemented using software
tools. The major objectives of the design process
are the identification of the software
components, the software architecture,
interfaces, data structures and algorithms.
31
Coding (implementation) The design must be
translated to a machine readable form. During
this stage the software design is realized as a
set of programs or program units. Programming
languages or CASE tools can be used to develop
software. Testing The testing process must ensure
that the system works correctly and satisfies the
requirements specified. After testing, the
software system is delivered to the customer.
32
Maintenance Software will undoubtedly undergo
changes after it is delivered to the customer.
Errors in the system should corrected and the
system should be modified and updated to suit new
user requirements.
33
Some Problems with the Waterfall Model

• It is often very difficult for the customer to
  state all requirements explicitly. The Waterfall
  model has the difficulty of accommodating the
  natural uncertainty that exists at the beginning
  of many projects.
• Real projects rarely follow the sequential flow
  that the model proposes. Although the Waterfall
  model can accommodate iteration, it does so
  indirectly.

34

• 3. The customers must have patience. A working
  version of the program(s) will not be available
  until late in the project time-span. A major
  blunder, if undetected until the working program
  is reviewed, can be disastrous.

35
Comment The Water Fall model is suitable
for projects which have clear and stable
requirements.
36
Prototyping It is very difficult for end-users to
anticipate how they will use new software systems
to support their work. If the system is large and
complex, it is probably impossible to make this
assessment before the system is built and put
into use. A prototype ( a small version of the
system) can be used to clear the vague
requirements. A prototype should be evaluated
with the user participation. There are two types
of Prototyping techniques Throw-away
Prototyping Evolutionary Prototyping
37
Throw-away and Evolutionary Prototyping
Executable prototype System specification
Throw-away prototyping
Outline Requirements
Evolutionary prototyping
Delivered system
38
Throw-away Prototyping
Delivered software system
39
Throw-away Prototyping The objective is to
understand the system requirements clearly.
Starts with poorly understood requirements. Once
the requirements are cleared, the system will be
developed from the beginning. This model is
suitable if the requirements are vague but stable.
40

• Some problems with Throw-away Prototyping
• Important features may have been left out of the
  prototype to simplify rapid implementation. In
  fact, it may not be possible to prototype some of
  the most important parts of the system such as
  safety-critical functions.
• An implementation has no legal standing as a
  contract between customer and contractor.
• Non-functional requirements such as those
  concerning reliability, robustness and safety
  cannot be adequately tested in a prototype
  implementation.

41
Evolutionary Prototyping
Develop abstract specification
Build prototype system
Evaluate prototype system
NO
System Adequate?
YES
Deliver system
42
Evolutionary prototyping Advantages Effort
of prototype is not wasted Faster than the
Waterfall model High level of user
involvement from the start Technical or
other problems discovered early risk reduced
mainly suitable for projects with vague and
unstable requirements.
43
Evolutionary Prototyping
(continued) Disadvantages Prototype usually
evolve so quickly that it is not cost- effective
to produce grate deal of documentation
Continual change tends to corrupt the structure
of the prototype system. Maintenance is
therefore likely to be difficult and costly.
It is not clear how the range of skills which is
normal in software engineering teams can be used
effectively for this mode of development.
Languages which are good for prototyping not
always best for final product.
44
The RAD Model
Team 3
Team 2
Business modeling
Team 1
Business modeling
Business modeling
Data modeling
Data modeling
Process modeling
Data modeling
Process modeling
Application generation
Process modeling
Application generation
Testing turnover
Application generation
Testing turnover
Testing turnover
60 90 days
45
The RAD Model
Rapid Application Development (RAD) is an
incremental 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 (eg. 60 to 90 days)
46
Processes in the RAD model
Business modelling The information flow in a
business system considering its
functionality. Data Modelling The information
flow defined as part of the business modelling
phase is refined into a set of data objects that
are needed to support the business Process
Modelling The data objects defined in the data
modelling phase are transformed to achieve the
information flow necessary to implement business
functions. Application generation RAD assumes the
use of 4GL or visual tools to generate the
system using reusable components. Testing and
turnover New components must be tested and all
interfaces must be fully exercised
47
Some problems with the RAD model

• RAD requires sufficient human resources to
  create right number of RAD teams
• RAD requires developers and customers who are
  committed to the rapid-fire activities necessary
  to get a system completed in a much abbreviated
  time frame.
• If a system cannot be properly modularized,
  building the components necessary for RAD will be
  problematic.
• RAD is not applicable when technical risks are
  high. This occurs when a new application makes
  heavy use of new technology or when the new
  software requires a high degree of
  interoperability with existing computer programs.

48
Incremental Model
49
Incremental Development The Incremental
development model involves developing the system
in an incremental fashion. The most important
part of the system is fist delivered and the
other parts of the system are then delivered
according to their importance. Incremental
development avoids the problems of constant
change which characterize evolutionary
prototyping. An overall system architecture is
established early in the process to act as a
framework. Incremental development is more
manageable than evolutionary prototyping as the
normal software process standards are followed.
Plans and documentation must be produced
50
Formal Development Model
high-level formal specification
51

• Formal Specification
• Formal software specifications are mathematical
  entities and may be analyzed using mathematical
  methods. Specification consistency and
  completeness can be proved mathematically.
• Formal specifications may be automatically
  processed. Software tools can be used to build
  programs from formal specifications.
• The development of a formal specification
  provides insights into and an understanding of
  the software requirements and the software design.

52

• Some problems with formal development methods
• Many software engineers have not been trained in
  the techniques required to develop formal
  specifications.
• Customers may be unwilling to fund development
  activities that they cannot easily monitor.
• Software management is inherently conservative
  and is unwilling to adopt new techniques for
  which payoff is not obvious.
• Most of the effort in specification research has
  been concerned with the development of languages
  and their theoretical aspects rather than tools
  and methods.

53
The Spiral Model This model is an evolutionary
software process model that couples the iterative
nature of prototyping with the controlled and
systematic aspects of the linear sequential
model. Using 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. The spiral
model is divided into four main task regions
Determine goals, alternatives,constraints
Evaluate alternatives and risks Develop and
test Plan
54
Key Points

• A disciplined development process is the
  cornerstone of software engineering.
• Different processes are appropriate in different
  circumstances.
• Regardless of the process to be adopted it should
  always be explicitly documented and the entry
  and exit criteria of all the constituent should
  be set down clearly.

55

• Review Questions
• The following are initial requirements specified
  by some customers. Identify the most suitable
  process models for these software projects.
• (a) I need to develop a simple library
  system for my school. I know the requirements
  very well
• (b) I need to develop a management
  information system for my organisation,. I may
  use it for all the branches in several location
  in Sri Lanka. I might use it on the Internet.
• (c ) I need to develop a software system
  to control a space shuttle

56
Review Questions (continued) 2. Complete the
table, placing a rank 1,2,3 in each cell