Software Development

1
Software Development

• Chapter 1

2
Chapter Contents

• 1.1 Problem Analysis and Specification
• 1.2 Design (Object-oriented design)
• 1.3 Coding
• 1.4 Testing, Execution, and Debugging
• 1.5 Maintenance

3
Software Development Process

• Phases in the Software Development Lifecycle
• Requirements Analysis
• Design
• Implementation
• Testing
• Maintenance
• Methodology for transition from the problem
  domain (client problem) to the solution domain (a
  computer).

4
Software Process

• The software process of an organization addresses
  all technical and management issues associated
  with the development of software and
  software-related artifacts within the
  organization.
• Software systems have become more and more
  complex, the need for a software process has
  increased.

5
Classic Waterfall Model
Waterfall Method, Sequentially perform the
software process phases. The development process
is completed in one run through the phases. Each
phase must be fully completed, documented and
correct.
6
Waterfall

• Problem with waterfall
• What if you have to go upstream
• That is, what happens when the requirements
  change?
• it is difficult to know exactly what is needed in
  each phase of the software process before some
  time is spent in the phase "following" it.
• Waterfall delays visible products until end of
  lifecycle

7
Iterative, incremental development process
An iteration results in an increment or growth
in the overall project.
8
Benefits of iterative, incremental method

• Enter new phases when prior phase is X (80?)
  complete
• Provides more continuity
• Look-ahead can provide better insights
• Cost reduction
• Accommodating the changing needs of the user
• But
• Milestones are more ambiguous

9
Boehms Spiral

• The waterfall is traversed several times,
  each iteration generate an intermediate
  prototype.
• evaluating the previous prototype in terms of its
  strengths, weaknesses, and risks
• defining the requirements of the next prototype
• planning and designing the next prototype
• constructing and testing the next prototype.

10
Spiral Model

• Early iterations are cheapest
• Each iteration provides more functionality at
  lower risk
• As costs increase, risks should decrease
• Good management control, well defined milestones
• Complex, large, expensive project
• May not be right for all projects

11
Development Process Requirements Analysis

• Objective Understand the problem the software
  product is supposed to solve (1st step in
  transition from client problem to solution domain
  the what).
• Output Software Requirements Specification (SRS)
  that specifies all functional and performance
  requirements

12
Problem Analysis and Specification

• CS or CE courses
• small systems
• few hundred lines of code
• simple, straightforward
• self-contained

• Real world
• large systems
• thousands or millions of lines of code
• complex
• many components
• problem initially poorly defined

12
13
Problem Analysis and Specification

• The specification (SRS) or "contract" will
  include
• Purpose
• Precondition (the state of processing before a
  program is executed)
• Postcondition (the state of processing after a
  program is executed)
• Real world contracts
• Must be precise
• May be required to prove end product meets these
  precise specifications

14
Problem Analysis and Specification

• CS courses
• small systems
• few hundred lines of code
• simple, straightforward
• self-contained

• Real world
• large systems
• thousands of lines of code
• complex
• many components
• problem initially poorly defined

14
15
Development Process DesignProcedural Design

• Original problem partitioned into simpler
  subproblems
• Example
• Update the students financial aid records by
  increasing the amounts by 10 percent.

16
Contrasting Program Design

• Procedure Oriented Object-Oriented

Data Operations
Control
Class
17
Object-Oriented DesignClass Object

• Class A collection of objects that have same
  type
• Object an instance of the class
• The class encapsulate the data and the operations
  on that data
• Example
• The collection of all financial aid awards make
  up a class FinancialAidAward

18
OOD Object-Oriented Design

• Identify the variables in the problem's
  specification and their types.
• Identify the operations or tasks to manipulate
  the objects

data members
function members
UML Unified Modeling Language
18
19
OOD Object-Oriented Design
Aggregation is a part of
The collection of all the students financial aid
records make up a class StudentAidRecord. The
arrow indicates that a StudentAidRecord contains
an array of FinancialAidAward objects
20
Algorithms (a sequence of operations)

• Pseudo code
• Must be
• Definite, unambiguous
• Simple
• Finite
• correct and efficient
• well structured (sequence, selection, repetition)
• Cannot separate data structures from algorithms
• Algorithms data structures Program

21
Algorithms

• Unstructured
• goto's
• if-else's

22
Coding (Implementation)

• Encode the design
• Example
• Figure 1.9 Financial-aid update function
• Figure 1.10 Test-driver for Financial-aid update
  function
• Figure 1.11 Header file (.h file)for
  FinancialAidAward class
• (header file stores the class declaration,
  includes the data member declaration and function
  member prototypes)
• Figure 1.12 Implementation file (.cpp file)for
  FinancialAidAward class
• (implementation file stores the definitions of
  function members)
• Provide a preview of C class

22
23
Coding

• Verify integration
• combining program units into a complete software
  system.
• Insure quality
• programs must be correct, readable, and
  understandable
• well-structured, documented, formatted for
  readability

pp25-pp30 coding style
24
Testing, Execution, and Debugging

• Verification "Are we building the product
  right?"
• check that products are correct,
• complete,
• consistent with each other and with those of the
  preceding phases.
• Validation "Are we building the right product?"
  
• check that documents, program modules, etc. match
  the customer's requirements.

24
25
Different Kinds Of Tests Required

• Unit tests
• Each individual program unit works?
• Program components tested in isolation
• Integration tests
• Units combined correctly?
• Component interface and information flow tested
• System tests
• Overall system works correctly?

25
26
Types of Errors

• Syntax errors
• errors in the grammar of the programming language
• Run-time errors
• happen during program execution
• (divide by zero, the square root of a negative
  number, dereference a null pointer)
• Logic errors
• errors in algorithm design
• the most difficult to locate

27
Black Box ( Functional Test)

• Outputs produced for various inputs
• Checked for correctness
• Do not consider structure of program component
  itself.
• Program unit is viewed as a black box
• Accepts inputs and produces outputs,
• Inner workings of the box are not visible.

27
28
White Box ( Structural Test)

• Performance is tested
• examine codes internal structure.
• Test data is carefully selected
• specific parts of the program unit are exercised.
• all possible path s that execution may follow are
  checked

28
29
Maintenance

• Large of
• Computer center budgets
• Programmer's time
• Software development cost
• Because
• Includes modifications and enhancements
• Poor structure, poor documentation, poor style
• Bug finding and fixing is tougher
• Impedes implementation of enhancements

29
30
Assignment Read Chapter 1 and Appendix C in the
Textbook!(Especially pp25-pp30 coding style)