System Development Approaches

1. System Development Approaches • Programs vs. software product: • Programs • developed by individuals for their personal use • usually small in size, limited functionality • may not have good user-interface • do not have proper users’ manuals • no documentation support

2. Software – a logical system element consisting of • Computer programs, that when executed provide desired function and performance • Data structures that enable the programs to manipulate the information adequately • Documentation that describe the operation and use of the programs

3. Software vs. hardware: • Software is developed - Hardware is manufactured • S/W does not wear out • S/W products are custom built rather than assembled from existing components • A software (sub)system is a subset of the entire system under study.

4. System Development Phases: • Feasibility study: • Preliminary system investigation • Based on the client’s request to change/enhance an existing system • Problem definition (overall study) • Existing system has poor response time • Unable to handle workload • Problem of cost, not economical

5. Problem of accuracy, reliability • Security problem • Feasibility study - Is the problem worth solving? • Assess alternative systems • Propose the most feasible, desirable system for the problem • Provides major overview of the problem • And acts as important checkpoint before committing more resources

6. Feasibility assessed in terms of four major categories: • Organizational feasibility – whether or not the proposed info system supports the strategic plan of the organization • Economic feasibility – costs and returns are evaluated to justify the investment in the system project • Questions addressed: • Cost of conducting a full system investigation

7. Cost of hardware and software for the class of application • Benefits in terms of reduced costs, improved customer service, improved resource utilization, fewer errors • Technical feasibility • Does the necessary technology exist to meet the needs w.r.t. speed, security, reliability? • Can it be acquired or developed? • Can the system be expanded?

8. Operational feasibility – willingness of the management, employees, customers, suppliers • Infeasible projects are abandoned – may be reworked upon and resubmitted • Methods of the preliminary investigation: • Reviewing documents • Interviewing selected persons

9. 2. Requirement Analysis and Specification: • Two distinct activities: • Requirements analysis - Assess the detailed/exact requirements of the customer • Requirements specification - Document the requirements properly • Analysis is a detailed study of the various operations of a business system along with its boundaries • Physical system is studied • Data flow diagrams are drawn • Data dictionaries are developed • A logical model is developed

10. Role of a system analyst is very important at this stage • 3. System Design: • Analysis specifies what a system should do • Design specifies how the Information System will achieve this objective • A top down approach is pursued • Two basic steps: • Architectural design – identifies major modules • Detailed design – each module is designed in detail

11. Three major areas of concern: • User interface design – interactions of the IS with the users • Data design – design of the logical structure of the database • Process design – implementation of the business logic • 4. Coding: Implementation • Translation of design into source code • Use a structured programming language, if analysis and design is done using a Structured approach

12. Use an object-oriented language, if analysis and design is done using object-oriented approach • Debugging • Documentation • 5. Testing: Test the software system for: • Correctness • Reliability • Robustness • Steps in testing: • Unit testing • Integration testing • System testing • Acceptance/validation testing

13. 6. Deployment and maintenance: • H/W and S/W acquisition • Site preparation – support infrastructure • Installation of the system • User training • Maintenance – monitoring, evaluating, modifying the system as per requirements • Corrective • Adaptive • Perfective

14. System Development Approaches: • System Development Life Cycle (process) – a series of identifiable stages that a software product undergoes during its lifetime • Each stage is called a life cycle phase • A software life cycle model (process model) – is a descriptive & diagrammatic model of a software life cycle • A life cycle model identifies the activities in each of the phases and establishes an ordering/precedence of the different phases • A development team should identify a suitable life cycle model, and adhere to it

15. Advantages of adhering to an SDLC model: • Ensures systematic development – disciplined • Develops understanding/enhancement of the model • Defines entry/exit criteria for each phase – project monitoring is easy for the project managers • 99% complete syndrome is obviated

16. Requirements Analysis and Specification Design Coding Testing Maintenance 1. Classical Waterfall Model Feasibility study

17. Diagrammatic, represents a cascade of waterfalls • Each phase is distinct and isolated from the rest • Strict completion of one phase can only lead to the beginning of the next phase • Cannot get back to a previous phase

18. Limitations: • Freezing requirements is difficult for a new system • Freezing requirements means freezing the H/W, which gets obsolete even before a system is deployed • Poor product visibility - A working model (prototype) of the system is not available until late in the life cycle model • Highly unsuitable for partial development and enhancements later • Suitable for automation of existing facilities.

19. 2. Prototyping: • A working model of the S/W that should be built, which is the result of a ‘quick design’ • Three types - based on presentation • A paper prototype/PC based model that shows the human-machine interactions • A working prototype implementing a subset of functionalities • An existing s/w having nearly the same features

20. Two types – based on the intent • Exploratory prototype (throwaway prototype) – intended to validate requirements, or to explore design choices • Evolutionary prototype – intended to evolve in steps into a finished product • Steps: • Identify user’s basic information requirements – i/o requirements; estimate cost of prototype itself • Develop an initial prototype – meets user’s basic requirements

21. Use the prototype to refine user’s requirements • Revise and enhance the prototype system • Repeat the steps till the prototype is refined to the satisfaction of the user • Advantages: • Ability to try out ideas with less costs • Adapts to frequent changes in requirements • A working model is always available with the user

22. Limitations: • May become a never ending process of refinement, which affects time, efforts and money • Management of the development process is difficult • 3. Iterative Enhancement Model: • The system is developed in increments • Each increment adds some more functionalities to the system • Continue until the full system is developed

23. Advantages: Combines the benefits of prototyping and waterfall model • Better testability with each increment than waterfall model • Provides feedback to the user at each stage • Limitations: • Does not give a complete system until late; many requirements may be overlooked • Time consuming and is not cost-effective

24. 4. Spiral Model: (proposed by Boehm - 1988) • Most recent model • Cyclic in nature • Angular dimension - progress made in the development process • Radial dimension – represents the total cost incurred so far • Steps: • Identify an objective – planning • Evaluate various options – risk analysis • Do a development – Engineering • Customer evaluation

25. Advantages: • Moves closer to the final goal – evolutionary approach • Uses prototyping as the risk reduction mechanism • Maintains the systematic stepwise approach suggested by the classical model, but uses an evolutionary/iterative framework, which reflects the real world more realistically • Most suitable for high-risk projects • Limitations: • May not be time and cost effective for small projects • Hybrid approach: • A combination of more than one model may be an accepted strategy

26. DISTRIBUTION OF SOFTWARE- DEVELOPMENT EFFORT Typical Product Life 5 – 10 years Development 1-2 years Ratio of development to maintenance: 40 / 60 Maintenance effort is often underestimated or unaccounted

27. Out of the total development effort – • Analysis & Design 40% • Implementation (coding) 20% • Testing 40% • Coding was often regarded as central activity • Testing consumes the most development time; often not planned well • Focus should shift from coding to other phases • Goal should be to reduce testing and maintenance effort.

28. SOFTWARE: ITS NATURE & QUALITIES • Software Qualities • External vs Internal Qualities • Product vs Process Qualities

29. Representative Qualities • Correctness, Reliability, Robustness • Performance • User Friendliness • Maintainability • Portability • Productivity

30. CORRECTNESS • Relationship between specification and behavior – “functional correctness” • Problem: usually no specification exists or is informal – leading to ambiguities • Assessed through • Experimental approach - testing • Analytical approach - verification • Enhanced through use of • High-level languages • Standard libraries

31. RELIABILITY • Software is reliable if the user can depend on it • Statistical behavior – probability that the software will operate as expected over a specified time interval. • Correctness is absolute – any deviation from requirement is incorrect. • Reliability is relative – if the consequence of an error is not serious, the software is still reliable • Correct programs are  of Reliable programs • (because small deviations are allowed)

32. ROBUSTNESS • Behavior in unanticipated circumstances e.g. Wrong data input • If the requirement specs does not specify what to do on error, a program may still be termed correct but not robust; Or, if it crashes on error (wrong data input) • Non-robust behavior will lead to refining specifications. • Requirement in spec – an issue of correctness • Not specified in spec – an issue of robustness

33. Some incorrect behavior tolerable – an issue of reliability • CRR applicable to product as well as process • Process is robust: accommodate unanticipated changes in the environment - programmers leaving halfway etc. • Process is reliable: consistently leads to high quality products.

34. PERFORMANCE & EFFICIENCY • Performance – measure of Response Time and Throughput • Efficiency – efficient, if uses computing resources economically & optimally • Important because it affects the usability of the system • Often addressed after an initial version is ready – sometimes difficult to improve without changing design.

35. USER-FRIENDLINESS • User friendly if human users find it easy to use • Subjective in nature • Example: verbose messages, menus or commands • User interface is a very important component • Human factors engineering ergonomics • Standardization helps

36. MAINTAINABILITY • Maintenance – modifications made after initial release • Incorrect word for software – better word is `software evolution’, so evolvability!! • Maintenance cost - 60% of total s/w costs • Corrective maintenance • Adaptive • Perfective

37. Corrective – removal of residual errors after it is delivered – about 20% of maintenance cost. • Adaptive – adjusting to new hardware platforms etc. – about 20% of maintenance cost. • Perfective – changing the software to improve some its qualities – about 60%

38. REPAIRABILITY • Allows correction of defects with minimum effort • In engineering, accessibility helps • Number of parts also affects • In software modularization helps • High level languages are easier to repair than assembly code

39. EVOLVABILITY • Evolvability normally decreases with evolution • Design for change – modularity PORTABILITY • Ability to run on different platforms - • hardware • software • Assume typical capabilities – platform support

40. PRODUCTIVITY • Quality of software production process • Individual vs. {team, organization} productivity • Re-usable modules increase productivity • Measures of productivity • KLOC/person hours