1

Phases in Software Development

Lecture 04

2

Software Development Lifecycle•Let us review the main steps

– Problem Definition– Feasibility Study– Analysis– System Design– Detailed Design– Implementation– Maintenance

•A separate planning step for large applications may be introduced after feasibility

3

Problem Statement• The problem statement is developed by the client

as a description of the problem addressed by the system

• Other words for problem statement:– Statement of Work

• A good problem statement describes – The current situation– The functionality the new system should support– The environment in which the system will be

deployed– Deliverables expected by the client– Delivery dates– A set of acceptance criteria

4

Feasibility Study•To get better understanding of problems and reasons by studying existing system, if available

– Are there feasible solutions?– Is the problem worth solving?

•Consider different alternatives•Essentially covers other steps of methodology (analysis, design, etc.) in a ‘capsule’ form

•Estimate costs and benefits for each alternative

5

Feasibility Study…•Make a formal report and present it to management and users; review here confirms the following:

– Will alternatives be acceptable– Are we solving the right problem– Does any solution promise a significant

return

•Users/management select an alternative

•Many projects ‘die’ here

6

Types of Feasibility

•Economical : will returns justify the investment in the project ?

•Technical : is technology available to implement the alternative ?

•Operational : will it be operationally feasible as per rules, regulations, laws, organizational culture, union agreements, etc. ?

7

Costs

•One-time (initial) costs include equipment, training, software development, consultation, site preparation

•Recurring costs include salaries, supplies, maintenance, rentals, depreciation

•Fixed and variable costs; vary with volume of workload

8

Benefits

•Benefits could be tangible (i.e. quantifiable) or intangible

•Saving (tangible benefits) could include

– Saving in salaries– Saving in material or inventory costs– More production– Reduction in operational costs, etc.

9

Benefits …

•Intangible benefits may include– Improved customer service– Improved resource utilization– Better control over activities (such as

production, inventory, finances, etc.)– Reduction in errors– Ability to handle more workload

10

Estimating Costs•How to estimate costs so early in the project?

– Decompose the system and estimate costs of components; this is easier and more accurate than directly estimating cost for the whole system

– Use historical data whenever available– Use organization's standards for computing

overhead costs (managerial/secretarial support, space, electricity, etc.)

– Personnel (for development and operations) costs are function of time, hence estimate time first

11

Financial Analysis•Consider time-value of money; while investment is today, benefits are in future!

•Compute present value P for future benefit F by

P = F/ (1+I)n

where I is prevailing interest rate and n is year of benefit

•Take into account ‘life’ of system: most systems have life of 5-7 years

12

Financial Analysis …•Cost is ‘investment’ in the project, benefits represent ‘return’

•Compute payback period in which we recover initial investment through accumulated benefits

•Payback period is expected to be less than system life !

•Are there better investment alternatives?

13

FEASIBILITY STUDY Report

1.0 Introduction:A brief statement of the problem, the environment in which the system is to be implemented, and constraints that affect the project

2.0 Management Summary and Recommendations:

Important findings and recommendations

3.0 Alternatives:A presentation of alternative system specifications; criteria that were used in selecting the final approach

FEASIBILITY STUDY

14

FEASIBILITY STUDY …

4.0 System Description An abbreviated version of information

contained in the System-Specification or reference to the specifications

5.0 Cost-Benefit Analysis6.0 Evaluation of Technical Risk7.0 Legal Ramifications (if any)8.0 Other Project-Specific Topics

15

System Identification•The development of a system is not just done

by taking a snapshot of a scene (domain)•Two questions need to be answered:

– How can we identify the purpose of a system? – Crucial is the definition of the system boundary:

What is inside, what is outside the system?•These two questions are answered in the

requirements process•The requirements process consists of two

activities: – Requirements Elicitation:

• Definition of the system in terms understood by the customer (“Problem Description”)

– Requirements Analysis: • Technical specification of the system in terms

understood by the developer (“Problem Specification”)

16

Requirements Elicitation•Very challenging activity•Requires collaboration of people with different backgrounds

– Users with application domain knowledge– Developer with solution domain knowledge

(design knowledge, implementation knowledge)

•Bridging the gap between user and developer:

– Scenarios: Example of the use of the system in terms of a series of interactions with between the user and the system

– Use cases: Abstraction that describes a class of scenarios

17

Types of Requirements Elicitation•Greenfield Engineering

– Development starts from scratch, no prior system exists, the requirements are extracted from the end users and the client

– Triggered by user needs– Example: Develop a game from scratch

•Re-engineering– Re-design and/or re-implementation of an existing

system using newer technology– Triggered by technology enabler– Example: Reengineering an existing game

• Interface Engineering– Provide the services of an existing system in a

new environment– Triggered by technology enabler or new market

needs– Example: Interface to an existing game

18

Requirement Elicitation Activities•Identifying Actors•Identifying Scenarios•Identifying use cases•Refining use cases•Identifying Relationships between actors and use cases

•Identifying Non functional Requirements

19

System Specification vs Analysis Model

•Both models focus on the requirements from the user’s view of the system.

•System specification uses natural language (derived from the problem statement)

•The analysis model uses formal or semi-formal notation (for example, a graphical language like UML)

•The starting point is the problem statement

20

Types of Requirements• Functional requirements: Describe the interactions between the

system and its environment independent from implementation– The watch system must display the time based on its

location

• Nonfunctional requirements: User visible aspects of the system not directly related to functional behavior.

– The response time must be less than 1 second– The accuracy must be within a second– The watch must be available 24 hours a day except from

2:00am-2:01am and 3:00am-3:01am

• Constraints (“Pseudo requirements”): Imposed by the client or the environment in which the system will operate

– The implementation language must be COBOL. – Must interface to the dispatcher system written in 1956.

21

Format of Requirement Analysis Document1. Introduction 1.1 Purpose of the system 1.2 Scope of the system 1.3 Objective and success criteria of the project 1.4 Definitions, acronyms, and abbreviations 1.5 References 1.6 Overview2. Current System3. Proposed System 3.1 Overview 3.2 Functional Requirements 3.3 Non Functional Requirements 3.3.1 Usability 3.3.2 Reliability 3.3.3 Performance 3.3.4 Supportability 3.3.5 Implementation 3.3.6 Interface 3.3.7 Packaging 3.3.8 Legal3.4 System Models 3.4.1 Scenarios 3.4.2 Use case model 3.4.3 Object Model 3.4.4 Dynamic model 3.4.5 User Interface4. Glossary