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 clients 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
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 users basic information requirements
  i/o requirements estimate cost of prototype
  itself
• Develop an initial prototype meets users basic
  requirements

21

• Use the prototype to refine users 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