Chapter 1

1.1 Introduction to software

Development

1
 Software Development Process

• Programming is a process of problem solving

• How do you start?
• Number of different approaches, or
methodologies
• Successful problem solvers follow a methodical
approach

2
Steps in the Program Development Process

1. Analyze the problem

2. Design a solution
3. Code the solution
4. Implement the code
5. Test and debug
6. Use an iterative approach

3
 Steps in the Program
Development Process

• Software development
process is iterative
• As errors are discovered, it
is often necessary to cycle
back to a previous phase or
step
Figure 1-13 Steps in the software
development process

4
 Step 1: Analyze the Problem

• Precisely what is software supposed to

accomplish?
• Understand the problem definition
• Review the problem specifications

5
 Analyze the Problem (continued)
• What kind of data will be available for input?
• What types of values (i.e., whole numbers,
alphabetic characters, and numbers with decimal
points) will be in each of the identified data
items?
• What is the domain (range of the values) for each
input item?
• Will the user of the program be inputting values?
• If the problem solution is to be used with multiple
data sets, are there any data items that stay the
same, or remain constant, with each set?
6
 Step 2: Design a Solution
• Several approaches
– Procedural and object-oriented methodologies
• Careful design always leads to better solutions
• Divide and Conquer
– Break the problem into smaller subtasks
– Top-down design, stepwise refinement
• Algorithms for the behaviors (object-oriented) or
processes (procedural) should be developed

7
 Design a Solution (continued)
• Algorithm
– Clear, unambiguous, step-by-step process for
solving a problem
– Steps must be expressed so completely and so
precisely that all details are included
– Instructions should be simple to perform
– Instructions should be carried out in a finite
amount of time
– Following the steps blindly should result in the
same results

8
 Design
• Object-oriented approach
• Class diagram
– Divided into three sections
• Top portion identifies the name of the class
• Middle portion lists the data characteristics
• Bottom portion shows what actions are to be
performed on the data

9
 Class Diagram

Figure 1-11 Class diagram of car rental agency

10
Class Diagram (continued)

Figure 1-15 Student class diagram

11
 Design (continued)
• Structured procedural approach
– Process oriented
– Focuses on the processes that data undergoes from
input until meaningful output is produced
• Tools used
– Flowcharts
– Pseudocode, structured English
• Algorithm written in near English statements for
pseudocode

12
 Flowchart
• Oval – beginning and end
• Rectangular – processes
• Diamond – decision to be
made
• Parallelogram – inputs and
output
• Flow line

Figure 1-14 Flowchart symbols

and their interpretation

13
 Step 3: Code the Solution
• After completing the design, verify the algorithm
is correct
• Translate the algorithm into source code
– Follow the rules of the language
• Integrated Development Environment (IDE)
– Visual Studio
• Tools for typing program statements, compiling,
executing, and debugging applications

14
 Step 4: Implement the Code
• Source code is compiled to check for rule
violations
• C# → Source code is converted into Microsoft
Intermediate Language (IL)
– IL is between high-level source code and native
code
– IL code not directly executable on any computer
– IL code not tied to any specific CPU platform
• Second step, managed by .NET’s Common
Language Runtime (CLR), is required

15
 Implement the Code
(continued)
• CLR loads .NET classes
• A second compilation,
called a just-in-time (JIT)
compilation is
performed
– IL code is converted to
the platform’s native
code
Figure 1-12
Execution steps for .NET

16
 Step 5: Test and Debug
• Test the program to ensure consistent results
• Test Driven Development (TDD)
– Development methodologies built around testing
• Plan your testing
– Test plan should include extreme values and
possible problem cases
• Logic errors
– Might cause abnormal termination or incorrect
results to be produced
– Run-time error is one form of logic error
17
 1.2 Programming Approaches
• Structured Procedural Programming
– Emerged in the 1970s
– Associated with top-down design
• Analogy of building a house
• Write each of the subprograms as separate
functions or methods invoked by a main controlling
function or module
– Drawbacks
• During software maintenance, programs are more
difficult to maintain
• Less opportunity to reuse code

18
• Object-oriented
– Newer approach
– Construct complex systems that
model real-world entities
– Facilitates designing components
– Assumption is that the world contains
a number of entities that can be
identified and described
19
Object-Oriented Methodologies
• Abstraction
– Through abstracting, determine attributes (data) and
behaviors (processes on the data) of the entities
• Encapsulation
– Combine attributes and behaviors to form a class
• Polymorphism
– Methods of parent and subclasses can have the
same name, but offer different functionality
• Invoke methods of the same name on objects of
different classes and have the correct method
executed

20
 Rapid application development
(RAD)
1
Rapid application development (RAD)
is a methodology in which a systems
designer produces prototypes for an
end-user. The end-user reviews the
prototype, and offers feedback on its
suitability. This process is repeated
until the end-user is satisfied with
the final system.

21
1.3 Rapid Application
Development

22
 What is RAD?
• Usable systems are built within a short period
of time
• In generic terms RAD is
– “Speedy development”
– “Shorter schedule”

23
 Principles of RAD
• 20/80 Rule: Usable 80% solution can be
developed in 20% of time required for the total
solution
• System can satisfy all business requirements
even if some operational requirements are not
satisfied
• A system can be accepted if it can satisfy
agreed minimum useful set of requirements

24
 Traditional Development Issues
• Cost and schedule overruns
• Product not fit for business
• High workload
• Projects get cancelled
• Friction among managers, developers and
customers

25
 Reasons for Project Failures
• Risks associated with teams
• Risks associated with technology
• Risks associated with requirements

26
 Conventional Methods!
• Long delay before customer sees the result
• Development takes longer time and business
may change meanwhile
• There is nothing until the entire project is
finished

27
 History of RAD
• Spiral model
• Evolutionary life cycle
• Rapid iterative productive prototyping
• RAD – Early 90s

28
 Classic Mistakes
• People related
• Product related
• Technology related
• Process related

29
 People Related Mistakes
• Undermined motivation
• Weak personnel
• Employee problems
• Heroics
• Unrealistic expectations
• Noisy offices
• Adding people to a late project
• Friction between customers and developers
30
 Product Related Mistakes
• Requirements gold plating
• Developer gold plating
• Feature creep
– Changes of the requirements occur for a long
period of time
• Push me….Pull me negotiation
• Research oriented development

31
 Technology Related Mistakes
• Silver Bullet Syndrome
– Too much rely on new technologies
• Switching tools at the middle of the project
– Learning curve, rework
• Overestimated savings from new tools or
methods
• Lack of automated source code control

32
 Process Related Mistakes
• Lack of risk management
• Contractor failure
• Lack of planning
• Premature convergence
• Planning to catch up later
– Code like hell programming
• Wastage of time at the fuzzy front end

33
 Why use RAD?
• Converging early to a design acceptable by the
customer
• Saving development time
• Preventing cost overruns
• Preventing runaway schedules

34
 Choose Most Rapid Model?
• How well the customer and the client
understand the requirements at the beginning
• Level of awareness about the system
architecture
• Amount of reliability
• How much planning ahead?

35
 1.4 Software Development
Principles
• The software should deliver the required
functionality and possess the following
attributes:
• 1. Maintainability
• 2. Dependability
• 3. Efficiency
• 4. Usability

36
 Maintainability

• A software must be flexible enough to

accommodate the changing needs and
deliver accordingly.

37
 Dependability

• A software must be trustworthy and

reliable to operate.

• A software should be dependable all the

time.

38
 Efficiency

• A software should be efficient.

• It should not make a wasteful use of system

resources.

39
 Usability

• A software should be usable by the users

for which it was designed.

40
END OF CHAPTER # 01

41