COS 102/CSC 120:

Computer as a Problem-Solving Tool

Topic 2:
Introduction to Programming
Lecture 2 Week3:
Lecturer
Dr. Ufuoma C. Ogude

Department of Computer Sciences

University of Lagos
1
Outlines of the Course
Wk2-7
 Concept of Problem solving
 Introduction to programming
 Concept & properties of Algorithm
 Fundamentals of programming (1): variable/variable
naming convention/data types in Python
 Fundamentals of programming (2): operators and
expressions
 Fundamentals of programming (3): control structures

2
 Introduction to
Programming
 Overview of Programming
Language
 Problem Solving Strategy
 Software Development Life Cycle
(SDLC)

3
 Design of
Algorithms
A person must translate an algorithm into a
computer program.

4
 Overview of
Programming
 A language is a system of communication. Humans
communicate with one another in some language, like
English, German or in many other languages.
 In order to make computers work for us, some sort of
instructions must be stored in a some kind of language.
And that language is called a Programming
Language.

5
 Programming
 To tell a computer to do something
 Programming is writing computer code to create a
program, to solve a problem.
 Programs consist of a series of instructions to tell a
computer exactly what to do and how to do it.
 Programs are created to implement algorithms.
Algorithms can be represented as pseudocode or
a flowchart, and programming is the translation of
these into a computer program.

Just as words are put together to form a sentence, a program6

puts one or more statements together to form an instruction.
 Programming Languages
s
 Used to develop new systems
 Multiple generations:
classification was used to indicate increasing power
of programming

• Fast
development
• Assembly • Use developer

2n
• Similar to
• Machine Code Language environments
spoken

1st 3rd 4th

• Zeros and • Used some that help
languages
Ones English like generate the

d
• Machine
• Machine phrases code
independent • Machine
dependent • Machine
• E.g., JAVA
dependent independent
• E.g., SQL and
SPSS

7
 Programming
Language
1st GL- Machine Languages (ML): Use binary coded instructions

2nd GL- Assembly Languages (AL): use symbolic coded

instructions

3rd GL - Higher Level Languages (HLL): use statements that are

close to English together with arithmetic notations

4th GL- 4GL are also known as very high level languages. They

8
Scripting languages such as SQL, Applescript, VBScript
 s
1GL:
 The first generation program language is pure
machine code, which is called machine language.
 The main drawbacks of machine language that
the code cannot be exported to other systems and
has to be rewritten, code is difficult to edit and
update.

2GL:
 The second-generation program language is
assembly language.
 The main problem of assembly language is that it
requires extensive knowledge of programming
and consumes a lot of time when writing a big 9
program.
 s
3GL:
 The third-generation language is called “high-
level" programming language.
 Third-generation programming languages
brought many programmer-friendly features to
code such as loops, conditionals, classes etc.
This means that one line of 3GL generation code
can produce many lines of object (machine)
code, saving a lot of time when writing programs.
 Third generation languages can be platform
independent, meaning that code written for one
system will work on another.
 To convert a third generation program into
machine language requires a Compiler or an 10

Interpreter.
 s
4GL:
 The fourth-generation language is designed to be
closer to natural human language than other high-
level languages.
 They are accessible to people without formal
training as programmers.
 They allow multiple common operations to be
performed with a single programmer-entered
command.
 They are intended to be easier for users.
 All 4GLs are designed to reduce programming
effort, the time it takes to develop software, and
the cost of software development.
 Some 4G languages are: FoxPro, LINC, FOCUS etc.
4G languages also use Complier or an Interpreter to 11

translate the language into machine code.

 s
5GL:
 Natural Languages represent the next step in the
development of programming languages, i.e fifth
generation languages.
 The text of a natural language statement very closely
resembles human speech.
 The use of natural language touches on expert
systems, computerized collection of the knowledge of
many human experts in a given field, and artificial
intelligence, independently smart computer systems
12
 s
5GL:
 Natural Languages represent
Expert Systems
Vision Systems
Speech/Voice recognition
Handwriting recognition
Robotics - Intelligent robots
Machine Learning & sub-fields
Neural networks, deep-learning

13
 s
 1st  4th
 Machine Code  Fast development
 Zeros and Ones  Use developer environments that help
 Machine dependent generate the code
 2nd  Machine independent
 Assembly Language  High Level Language
 Used some English  User friendly, Similar to natural
like phrases languages
 Machine dependent  Platform independent
 3rd  Easy to write or remember
 Similar to spoken  Easy to learn and work
languages  While execution: translated into
 Machine assembly language then to machine
independent language.
 Slow in execution but is efficient for
14
developing programs.

 Programming
Language
 A programming language is a set of written symbols that

instructs the computer hardware to perform specific tasks.

 Typically, a programming language consists of a

vocabulary and a set of rules (called syntax) that the

programmer must learn".

It lets the programmer express data processing in a

symbolic manner without regard to machine-specific

details.
15
 Programming
Language
 The language is made up of series of statements that fit

together to form instructions.

These instructions tell a computer what to do.

16
 Programming
Language
 There are many different programming languages, some
more complicated and complex than others.
Among the most popular languages are:
 Python
 Java
 C++
 BASIC
 Scratch

17
Programming Language
Cont’d
 Different languages work in different ways.
For example, in Python all instructions are written in
lowercase, but in BASIC they tend to be written in
uppercase.
 Programming languages are designed to be easy for a
human to understand and write in. However, a
computer cannot run programs written in these
languages directly.
 Most programming languages must be translated
into machine code before the computer
18

can execute the instructions.

 ls
 Programming involves activities such as
 analysis,
 developing
 understanding,
 generating algorithms,
 verification of requirements of algorithms
including their correctness and resources
consumption, and
 implementation (commonly referred to
as coding) of algorithms in a 19

target programming language

 Elements
 There are five basic programming
elements:
 Input-Output Instruction
 Arithmetic Instruction
 Conditional Instruction , and
 Looping Instruction

20
 Program
 Program s a sequence of instructions that a computer
follows to solve a problem. A program is written in a
computer language.
Most of the languages have been created to fit particular
classes of problems.
The process of collecting requirements, analyzing a
problem and designing its solution as well as
writing and maintaining a computer program is
called software development
 Programs are made up of statements that the
programming language knows and understands.
21

Each statement tells the computer to perform a specific

Statements
 Different programming languages use different
statements. A few of these are listed in this table:

22
 Software
Development
 Programming: Needed to take ideas or business

solutions and bringing them to reality.

 Small changes can be implemented in a short

timeframe with a streamlined process

 Larger changes will require a software development

methodology to guide and manage the process:

 Systems development life cycle (SDLC)

.
23
Software Development Life
Cycle (SDLC)
 SDLC is a conceptual model which includes policies and

procedures for developing or altering systems throughout

their life cycles.

 SDLC is the application of standard business practices to

building software applications.

 The SDLC aims to produce a high-quality software that

meets or exceeds customer expectations, reaches

completion within times and cost estimates. 24

Software Development Life
Cycle (SDLC)
 An effective SDLC should result in a high quality system

that meets customer expectations, reaches completion

within time and cost evaluations, and works effectively

and efficiently in the current and planned Information

Technology infrastructure.

25
 SDLC
 SDLC is a systematic approach which explicitly breaks down the
work into phases that are required to implement either new or
modified System. It is used by analysts to develop a system.
 Phases:-
1. Preliminary Analysis
2. Systems Analysis
3. Systems Design
4. Programming
5. Testing
6. Implementation
7. Maintenance
 Some project managers will combine, split, or omit steps,
depending on the project’s scope.
 These are the core components recommended for all software
26

development projects.
SDLC

27
 Phases
1. Preliminary Analysis:– requests are reviewed
Deliverable - feasibility analysis document
2. Systems Analysis – if approved, determine the system
requirements for new system
Deliverable – systems requirement document
3. Systems Design:– converts system analysis requirements into
system design document deliverable
4. Programming:– coding commences using design documents
5. Testing:– ensures that the code functions according to
requirements
6. Implementation:- converting from old system to new system
28

Training, documenting functions, and data conversion

 Models
 A framework that describes the activities performed at
each stage of a software development project.
 SDLC models specify and design, which are followed
during the software development phase.
 These models are also called "Software
Development Process Models."
Each process model follows a series of phase unique to
its type to ensure success in the step of software
development.

29
 Models
 Here, are some important phases of SDLC life
cycle:
 Waterfall Model
 RAD Model
 Spiral Model
 V-Model
 Incremental Model
 Agile Model
 Iterative Model
 Big bang Model 30
 Study
Study the following:
 SDLC Phases
 SDLC Models: Advantages and
Disadvantages, and Applications

31
 Python
 Python is a Scripting programming language known for both
its simplicity and wide breadth of applications. For this
reason it is considered one of the best languages for
beginners.
 Python is a powerful and flexible programming language.
It uses concise and easy-to-learn syntax which enables
programmers to write more codes and develop more
complex programs in a much shorter time.
 Used for everything from Web Development to Scientific
Computing
 Python is referred to as a “general purpose” language by
32

the greater programming community.

 Python
 Python is an object-oriented programming language
created by Guido Rossum in 1989.
It is ideally designed for rapid prototyping of complex
applications. It has interfaces to many OS system calls
and libraries and is extensible to C or C++.
Many large companies use the Python programming
language, including NASA, Google, YouTube, BitTorrent,
etc.

33
 Next Lecture:
Week4
 Concept & properties of Algorithm, Role of
Algorithm in problem solving process, Design
of Algorithms, Pseudocode, Flowcharting

34
Model
 Requirements – defines
needed information,
function, behavior,
performance and
interfaces.
 Design – data structures,
software architecture,
interface representations,
algorithmic details.
 Implementation – source
code, database, user
documentation, testing.
 Waterfall
Strengths
 Easy to understand, easy to use
 Provides structure to inexperienced staff
 Milestones are well understood
 Sets requirements stability
 Good for management control (plan, staff, track)
 Works well when quality is more important than
cost or schedule
 Waterfall
Deficiencies
 All requirements must be known upfront
 Deliverables created for each phase are considered frozen –
inhibits flexibility
 Can give a false impression of progress
 Does not reflect problem-solving nature of software
development – iterations of phases
 Integration is one big bang at the end
 Little opportunity for customer to preview the system (until
it may be too late)
 When to use the
Waterfall Model
 Requirements are very well known

 Product definition is stable

 Technology is understood

 New version of an existing product

 Porting an existing product to a new platform.

V-Shaped SDLC
Model
 A variant of the
Waterfall that
emphasizes the
verification and
validation of the
product.
 Testing of the product
is planned in parallel
with a corresponding
phase of development
 Steps
 Project and Requirements  Production, operation and
Planning – allocate resources maintenance – provide for
enhancement and corrections
 Product Requirements and  System and acceptance
Specification Analysis – testing – check the entire
complete specification of the software system in its
software system environment

 Architecture or High-Level
Design – defines how software  Integration and Testing –
functions fulfill the design check that modules
interconnect correctly
 Detailed Design – develop
algorithms for each  Unit testing – check that each
architectural component module acts as expected

 Coding – transform
algorithms into software
V-Shaped Strengths
 Emphasize planning for verification and
validation of the product in early stages of
product development
 Each deliverable must be testable
 Project management can track progress by
milestones
 Easy to use
V-Shaped Weaknesses
 Does not easily handle concurrent events
 Does not handle iterations or phases
 Does not easily handle dynamic changes
in requirements
 Does not contain risk analysis activities
When to use the V-Shaped
Model
 Excellent choice for systems requiring high
reliability – hospital patient control
applications
 All requirements are known up-front
 When it can be modified to handle
changing requirements beyond analysis
phase
 Solution and technology are known
Structured Evolutionary
Prototyping Model
 Developers build a prototype during the
requirements phase
 Prototype is evaluated by end users
 Users give corrective feedback
 Developers further refine the prototype
 When the user is satisfied, the prototype
code is brought up to the standards
needed for a final product.
Structured Evolutionary
Prototyping Steps
 A preliminary project plan is developed
 An partial high-level paper model is created
 The model is source for a partial requirements
specification
 A prototype is built with basic and critical
attributes
 The designer builds
 the database
 user interface
 algorithmic functions
 The designer demonstrates the prototype, the
user evaluates for problems and suggests
improvements.
 This loop continues until the user is satisfied
Structured Evolutionary
Prototyping Strengths
 Customers can “see” the system
requirements as they are being gathered
 Developers learn from customers
 A more accurate end product
 Unexpected requirements accommodated
 Allows for flexible design and development
 Steady, visible signs of progress produced
 Interaction with the prototype stimulates
awareness of additional needed
functionality
Structured Evolutionary
Prototyping Weaknesses
 Tendency to abandon structured program development
for “code-and-fix” development
 Bad reputation for “quick-and-dirty” methods
 Overall maintainability may be overlooked
 The customer may want the prototype delivered.
 Process may continue forever (scope creep)
When to use
Structured Evolutionary
Prototyping
 Requirements are unstable or have to be
clarified
 As the requirements clarification stage of a
waterfall model
 Develop user interfaces
 Short-lived demonstrations
 New, original development
 With the analysis and design portions of
object-oriented development.
Rapid Application Model
(RAD)
 Requirements planning phase (a workshop utilizing
structured discussion of business problems)
 User description phase – automated tools capture
information from users
 Construction phase – productivity tools, such as code
generators, screen generators, etc. inside a time-box.
(“Do until done”)
 Cutover phase -- installation of the system, user
acceptance testing and user training
RAD Strengths
 Reduced cycle time and improved productivity with
fewer people means lower costs
 Time-box approach mitigates cost and schedule risk
 Customer involved throughout the complete cycle
minimizes risk of not achieving customer satisfaction
and business needs
 Focus moves from documentation to code (WYSIWYG).
 Uses modeling concepts to capture information about
business, data, and processes.
RAD Weaknesses
 Accelerated development process must
give quick responses to the user
 Risk of never achieving closure
 Hard to use with legacy systems
 Requires a system that can be
modularized
 Developers and customers must be
committed to rapid-fire activities in an
abbreviated time frame.
When to use RAD
 Reasonably well-known requirements
 User involved throughout the life cycle
 Project can be time-boxed
 Functionality delivered in increments
 High performance not required
 Low technical risks
 System can be modularized
Incremental SDLC
Model
 Construct a partial
implementation of a total
system
 Then slowly add
increased functionality
 The incremental model
prioritizes requirements
of the system and then
implements them in
groups.
 Each subsequent release
of the system adds
function to the previous
release, until all designed
functionality has been
implemented.
Incremental Model
Strengths
 Develop high-risk or major functions first
 Each release delivers an operational
product
 Customer can respond to each build
 Uses “divide and conquer” breakdown of
tasks
 Lowers initial delivery cost
 Initial product delivery is faster
 Customers get important functionality
early
 Risk of changing requirements is reduced
Incremental Model
Weaknesses
 Requires good planning and design
 Requires early definition of a complete and
fully functional system to allow for the
definition of increments
 Well-defined module interfaces are
required (some will be developed long
before others)
 Total cost of the complete system is not
lower
When to use the Incremental
Model
 Risk, funding, schedule, program
complexity, or need for early realization of
benefits.
 Most of the requirements are known up-
front but are expected to evolve over time
 A need to get basic functionality to the
market early
 On projects which have lengthy
development schedules
 On a project with new technology
Spiral SDLC Model
 Adds risk analysis,
and 4gl RAD
prototyping to the
waterfall model
 Each cycle involves
the same sequence
of steps as the
waterfall process
model
 Spiral Quadrant
Determine objectives, alternatives and
constraints

 Objectives: functionality, performance,

hardware/software interface, critical success
factors, etc.
 Alternatives: build, reuse, buy, sub-contract, etc.
 Constraints: cost, schedule, interface, etc.
 Spiral Quadrant
Evaluate alternatives, identify and resolve
risks
 Study alternatives relative to objectives and
constraints
 Identify risks (lack of experience, new technology,
tight schedules, poor process, etc.
 Resolve risks (evaluate if money could be lost by
continuing system development
 Spiral Quadrant
Develop next-level product
 Typical activites:
 Create a design
 Review design
 Develop code
 Inspect code
 Test product
Spiral Quadrant
Plan next phase
 Typical activities
 Develop project plan
 Develop configuration management plan
 Develop a test plan
 Develop an installation plan
Spiral Model Strengths
 Provides early indication of
insurmountable risks, without much cost
 Users see the system early because of
rapid prototyping tools
 Critical high-risk functions are developed
first
 The design does not have to be perfect
 Users can be closely tied to all lifecycle
steps
 Early and frequent feedback from users
 Cumulative costs assessed frequently
Spiral Model Weaknesses
 Time spent for evaluating risks too large for small
or low-risk projects
 Time spent planning, resetting objectives, doing
risk analysis and prototyping may be excessive
 The model is complex
 Risk assessment expertise is required
 Spiral may continue indefinitely
 Developers must be reassigned during non-
development phase activities
 May be hard to define objective, verifiable
milestones that indicate readiness to proceed
through the next iteration
 When to use Spiral
Model
 When creation of a prototype is appropriate
 When costs and risk evaluation is important
 For medium to high-risk projects
 Long-term project commitment unwise because of potential
changes to economic priorities
 Users are unsure of their needs
 Requirements are complex
 New product line
 Significant changes are expected (research and exploration)
Agile SDLC’s
 Speed up or bypass one or more life cycle
phases
 Usually less formal and reduced scope
 Used for time-critical applications
 Used in organizations that employ
disciplined methods
Some Agile Methods
 Adaptive Software Development (ASD)
 Feature Driven Development (FDD)
 Crystal Clear
 Dynamic Software Development Method
(DSDM)
 Rapid Application Development (RAD)
 Scrum
 Extreme Programming (XP)
 Rational Unify Process (RUP)
Extreme Programming - XP
For small-to-medium-sized teams developing
software with vague or rapidly changing
requirements
Coding is the key activity throughout a
software project
 Communication among teammates is done
with code
 Life cycle and behavior of complex objects
defined in test cases – again in code
Feature Driven Design
(FDD)
Five FDD process activities
1. Develop an overall model – Produce class and sequence
diagrams from chief architect meeting with domain experts and
developers.
2. Build a features list – Identify all the features that support
requirements. The features are functionally decomposed into
Business Activities steps within Subject Areas.
Features are functions that can be developed in two weeks and expressed in
client terms with the template: <action> <result> <object>

i.e. Calculate the total of a sale

3. Plan by feature -- the development staff plans the development
sequence of features
4. Design by feature -- the team produces sequence diagrams for
the selected features
5. Build by feature – the team writes and tests the code

http://www.nebulon.com/articles/index.html
Dynamic Systems Development
Method (DSDM)
Applies a framework for RAD and short time
frames

Paradigm is the 80/20 rule

– majority of the requirements can be
delivered in a relatively short amount of
time.
DSDM Principles
1. Active user involvement imperative
(Ambassador users)
2. DSDM teams empowered to make decisions
3. Focus on frequent product delivery
4. Product acceptance is fitness for business
purpose
5. Iterative and incremental development - to
converge on a solution
6. Requirements initially agreed at a high level
7. All changes made during development are
reversible
8. Testing is integrated throughout the life cycle
9. Collaborative and co-operative approach among
all stakeholders essential
DSDM Lifecycle
 Feasibility study
 Business study – prioritized requirements
 Functional model iteration
 risk analysis
 Time-box plan
 Design and build iteration
 Implementation
Adaptive SDLC
Combines RAD with software engineering
best practices
 Project initiation
 Adaptive cycle planning
 Concurrent component engineering
 Quality review
 Final QA and release
Adaptive Steps
1. Project initialization – determine intent of
project
2. Determine the project time-box
(estimation duration of the project)
3. Determine the optimal number of cycles
and the time-box for each
4. Write an objective statement for each
cycle
5. Assign primary components to each
cycle
6. Develop a project task list
7. Review the success of a cycle
8. Plan the next cycle
Tailored SDLC Models
 Any one model does not fit all projects
 If there is nothing that fits a particular
project, pick a model that comes close and
modify it for your needs.
 Project should consider risk but complete
spiral too much – start with spiral & pare it
done
 Project delivered in increments but there
are serious reliability issues – combine
incremental model with the V-shaped
model
 Each team must pick or customize a SDLC
model to fit its project
Quality – the degree to which the
software satisfies stated and implied
requirements
 Absence of system crashes
 Correspondence between the software and the
users’ expectations
 Performance to specified requirements

Quality must be controlled because it lowers

production speed, increases maintenance costs
and can adversely affect business
Quality Assurance Plan
 The plan for quality assurance activities should be
in writing
 Decide if a separate group should perform the
quality assurance activities
 Some elements that should be considered by the
plan are: defect tracking, unit testing, source-
code tracking, technical reviews, integration
testing and system testing.
Quality Assurance
Plan
 Defect tracing – keeps track of each defect found, its
source, when it was detected, when it was resolved, how it
was resolved, etc
 Unit testing – each individual module is tested
 Source code tracing – step through source code line by line
 Technical reviews – completed work is reviewed by peers
 Integration testing -- exercise new code in combination
with code that already has been integrated
 System testing – execution of the software for the purpose
of finding defects.