1. 1 Phases in Software Development Lecture 04

2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 Analysis 6.0 Evaluation of Technical Risk 7.0 Legal Ramifications (if any) 8.0 Other Project-Specific Topics

15. 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. 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. 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. 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. 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. 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. 21 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