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 program puts one or more
6
statements together to form an instruction.
 Generations
❑ Programming Languages
▪ Used to develop new systems
▪ Multiple generations:
classification was used to indicate increasing power
of programming

• Fast
development
• Assembly • Use developer
• Similar to
• Machine Code Language environments
spoken

1st 2nd 3rd 4th

• Zeros and • Used some languages that help
Ones English like generate the
• Machine code
• Machine phrases
independent
dependent • Machine • Machine
• E.g., JAVA independent
dependent
• 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

Scripting languages such as SQL, Applescript, VBScript

5th GL- Natural language; Automatic code generation 8

 Generations
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 program.
➢ The program codes are not also machined independent. 9
 Generations
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 Interpreter. 10
 Generations
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
translate the language into machine code. 11
 Generations
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
 Generations
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
 Generations
 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 like  User friendly, Similar to natural languages
phrases  Platform independent
➢ Machine dependent  Easy to write or remember
 3rd  Easy to learn and work
➢ Similar to spoken  While execution: translated into assembly
languages language then to machine language.
➢ Machine independent  Slow in execution but is efficient for
developing programs.
 Ex: C, C++, Python, Java etc. 14
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.

Programming languages can be used to create programs that

control the behavior of a machine and/or to express algorithms

15

precisely.
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 can execute the
instructions.
18
 Fundamentals
❑ 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 target programming language

19
 Basic 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.
Each statement tells the computer to perform a specific task,
21
and the instructions tell a computer what to do
 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
 Phases of 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.
Phases of SDLC

27
 SDLC 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
Training, documenting functions, and data conversion
28
7. Maintenance:– support for reporting prioritizing, and fixing bugs
 SDLC 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
 SDLC 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
▪ Prototype Model 30
 Further 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 the
greater programming community.
32
 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
Waterfall 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
 V-Shaped 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  Integration and Testing –
software functions fulfill the check that modules
design interconnect correctly

 Detailed Design – develop  Unit testing – check that each

algorithms for each module acts as expected
architectural component
 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.