Phases in Software Development Lecture 04 1 Software

Phases in Software Development Lecture 04 1

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 2

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 3

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 4

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 5

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. ? 6

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 7

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. 8

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 9

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 10

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 11

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? 12

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 13

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 Analysis 6. 0 Evaluation of Technical Risk 7. 0 Legal Ramifications (if any) 8. 0 Other Project-Specific Topics 14

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”) 15

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 16

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 17

Requirement Elicitation Activities • Identifying Actors • Identifying Scenarios • Identifying use cases • Refining use cases • Identifying Relationships between actors and use cases • Identifying Non functional Requirements 18

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 19

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: 00 am-2: 01 am and 3: 00 am-3: 01 am • 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. 20

Format of Requirement Analysis Document 1. 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 Overview 2. Current System 3. 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 Legal 3. 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 Interface 4. Glossary 21