Software

Engineering
CS508
SECTIONS
SW Engineering

 SW Engineering is about understanding

1. business problems
2. inventing solutions
3. evaluating alternatives
4. and making design tradeoffs and choices.
 It is helpful to document the process.
 It is not about writing documentation.
 It is about delivering value (Code, Documentation) for the
customer
SW Engineering Lifecycle

 Planning
 analysis
 Design
 Implementation
 Testing / Maintenance
SW Engineering Models

 Waterfall Model
 Iterative Model
 Spiral Model
 V-Model
 Big Bang Model
 Agile Model
 RAD Model
 Rapid Application Model
Waterfall Model
Waterfall model steps
 1. Requirements Specification
- Understanding the usage scenarios and deriving the static domain model
 2. Design
- Assigning responsibilities to objects and specifying detailed dynamics of their
interactions under different usage scenarios
 3. Implementation
- Encoding the design in a programming language
 4. Testing
- Individual classes/components (unit testing) and the entire system (integration
testing)
 5. Operation and Maintenance
- Running the system; Fixing bugs and adding new features
Agile Model
Agile Characteristics

 Break the big problem down into smaller pieces (increments) and
prioritize them.
 In each iteration progress through the development in more
depth.
 Seek the customer feedback and change course based on
improved understanding.
 Decomposing a problem into simpler ones, so called divide-and-
conquer approach, In software development it is embodied in
modularity.
 Modularity: source code for a module can be written and
maintained independently of the source code for other modules.
1-Planning

 It identifies whether or not there is the need for a new system to

achieve a business's strategic objectives.
 This is a preliminary plan (or a feasibility study) for a company's
business initiative to acquire the resources to build on an
infrastructure to modify or improve a service.
 The company might be trying to meet or exceed expectations for
their employees, customers and stakeholders too.
 The purpose of this step is to find out the scope of the problem
and determine solutions. Resources, costs, time, benefits and
other items should be considered at this stage.
1- Planning
 It’s not in our scope. Project Management is responsible for this phase.
Project management steps:
 Feasibility Studies
 Project Planning
 Project Governance
 Project Success Criteria
 Benefits Planning & Realization
 Resource Allocation
 Risk Assessment and Management
 Ethics and Projects
 Implementation of Project Plan
 Earned Value Management
 Communicating Your Plans and Status
 Evaluating Projects and Results
 When Projects Are in Trouble
2-Analysis: Requirement Process

 The goal of this phase is to : produce the system specifications

by:
1. delimits the system and specifies the services it offers.
2. identifies the types of users that will interact with the system.
3. identifies other systems that interact with our system.

Requirement Process consists of three parts:

4. Requirements gathering
5. Requirements analysis
6. Requirements specification
1-Requirement Gathering

 It also known as “Requirement Elections”, helps developer to

understand the business context.
 The customer will define:
1. What’s required in the system.
2. What’s to be accomplished by the system.
3. How the system will fit into the needs of the business.
4. how the system will be used on a day-to-day basis
2-Requirement Analysis

 Refining of and reasoning about the requirements received from

the customer during requirements gathering.
 Negotiation with the customer will be needed to
1. Determine the priorities.
2. What is essential, and what is realistic.
Analysis is driven by the creation and elaboration of user scenarios
that describe how the end-user will interact with the system.
3-Requirements specification
 It represents the problem statement in a semiformal or formal manner
to ensure clarity, consistency, and completeness.
 It describes
1. Functions of the software-to-be.
2. Quality of the software-to-be.
3.The constrains that will govern its development.
A specification can be a
 written document
 a set of graphical models
 a formal mathematical model, a collection of usage scenarios (or, “use
cases”)
 a prototype, or any combination of these
Types of Requirements

 Functional requirements
 Non-Functional requirements
Functional Requirements

 Determine the system’s expected behavior and the effects it

should produce in the problem domain.
 These requirements generally represent the main product
features.
Non-functional Requirements

 Describe some quality characteristic that the system-to-be shall exhibit.

 The term FURPS+ refers to the non-functional system properties:
o Functionality lists additional functional requirements that might be
considered, such as security, which refers to ensuring data integrity and
authorized access to information
o Usability refers to the ease of use, esthetics, consistency, and
documentation—a system that is difficult and confusing to use will likely
fail to accomplish its intended purpose
o Reliability specifies the expected frequency of system failure under
certain operating conditions, as well as recoverability, predictability,
accuracy, and mean time to failure
o Performance details the computing speed, efficiency, resource
consumption, throughput, and response time
Guidelines of Requirement
documenting
 Software system requirements are usually written in the form of
statements “The system shall …” or “The system should …”
 The “shall” form is used for features that must be
implemented.
 The “should” form for desirable but not mandatory features.
 All requirements must be written so that they are testable in
that it should be obvious how to write acceptance tests that
would demonstrate that the product meets the requirement.
Requirement priorities

 Not all requirements can be realized because of budgetary or

time constraints. Therefore, it is necessary to prioritize the
requirements.
1. Essential: have to be realized to make the system acceptable to
the customer.
2. Desirable: highly desirable, but not mandatory requirements
3. Optional: might be realized if time and resources permit
4. Future: will not be realized in the current version of the system-
to-be, but should be recorded for consideration in future versions
Use Case Diagram

 Used to gather requirements of a system.

 How to draw it:-

Use Case
“Function”

Actor
Use Case Diagram

Includes
 If multiple use cases contain a common sequence of events:
–Extract these events into a new abstract use case
–Change the original use cases to call the new abstract use case
–The abstract use case is never used on its own
Use Case Diagram

Extend
 Use cases can be extended with additional details
•Understand the basic requirements, then introduce
complexity
•The extended use case documents the differences
Includes & Extend Example:
Actor description

 Actor : Actor Name

 Description: Describe the actor role.

Example:
Actor : Customer
Description: request to open an account , dispose and withdraw
funds.
Use Case description

Use Case : Withdraw Cash

Initiating Actor: Customer
Initiating Event:
Pre-conditions: Customer account exists
Post-conditions:
Includes: Update balance
Extends:
Business Rules:
Customer identifies himself and his account. Customer chooses to withdraw cash,
Customer specifies the amount required. Either the cash specified will be returned,
the customer's account will be amended for the transaction, and the balance
decremented, or no cash will be given and the customer's account will be
unaffected.
Use case Scenarios
Scenario ID 1
Scenario Description The Customer withdraw available amount of cash successfully.
Use Case Withdraw Cash
Initiating actor Customer
Include Update Balance
Precondition The user has a valid account
Action Exception
1. Customer enters his/her  
account number.
2. System checks the (1)
customer’s account number.
3. Customer enter available  
withdraw amount.
4. System will give him the
money and update balance
will be activated
Post condition Cash will dispensed and balance updated
Use case Scenarios
Scenario ID 1

Exception Description System response

number

1 Wrong account number 1. Show error message

2. Clear account field
3. Log in form is displayed again
Bank ATM : Case study
 A bank has several automated teller machines (ATMs), which are
geographically distributed and connected via a wide area network to a
central server. Each ATM machine has a card reader, a cash dispenser,
a keyboard/display, and a receipt printer. By using the ATM machine, a
customer can withdraw cash from either checking or savings account,
query the balance of an account, or transfer funds from one account to
another. A transaction is initiated when a customer inserts an ATM card
into the card reader. Encoded on the magnetic strip on the back of the
ATM card are the card number, the start date, and the expiration date.
Assuming the card is recognized, the system validates the ATM card to
determine that the expiration date has not passed, that the user-
entered PIN (personal identification number) matches the PIN
maintained by the system, and that the card is not lost or stolen. The
customer is allowed three attempts to enter the correct PIN; the card is
confiscated if the third attempt fails. Cards that have been reported lost
or stolen are also confiscated.
Bank ATM : Case study

 If the PIN is validated satisfactorily, the customer is prompted for a

withdrawal, query, or transfer transaction. Before withdrawal transaction
can be approved, the system determines that sufficient funds exist in the
requested account, that the maximum daily limit will not be exceeded,
and that there are sufficient funds available at the local cash dispenser. If
the transaction is approved, the requested amount of cash is dispensed,
a receipt is printed containing information about the transaction, and the
card is ejected. Before a transfer transaction can be approved, the
system determines that the customer has at least two accounts and that
there are sufficient funds in the account to be debited. For approved
query and transfer requests, a receipt is printed and card ejected. A
customer may cancel a transaction at any time; the transaction is
terminated and the card is ejected. Customer records, account records,
and debit card records are all maintained at the server.
Bank ATM : Case study

 An ATM operator may start up and close down the ATM to

replenish the ATM cash dispenser and for routine maintenance. It
is assumed that functionality to open and close accounts and to
create, update, and delete customer and debit card records is
provided by an existing system and is not part of this problem.
 ATM: Automated Teller Machine
 PIN: Personal Identification Number