2 lecture week 3

Study Summary: COS 102/CSC 120 - Computer as a Problem-Solving Tool

Topic 2: Introduction to Programming (Lecture 2, Week 3)

Lecturer: Dr. Ufuoma C. Ogude
Department: Computer Sciences
University: University of Lagos

Course Outlines (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

Introduction to Programming Overview

This section covers:

• Overview of Programming Language
• Problem Solving Strategy
• Software Development Life Cycle (SDLC)

Design of Algorithms

• A person must translate an algorithm into a computer program.
• Algorithm: A sequence of instructions describing how to do a task (or process).

Overview of Programming

• A language is a system of communication (e.g., English, German).
• To make computers work, instructions must be stored in a language called a Programming Language.

Programming

• Programming: Writing computer code to create a program to solve a problem.
• Programs: Consist of a series of instructions telling a computer exactly what to do and how to do it.
• Programs are created to implement algorithms, which can be represented as pseudocode or flowcharts. Programming is the translation of these into a computer program.
• A program puts one or more statements together to form an instruction.

Generations of Programming Languages

Programming languages are classified into multiple generations to indicate increasing power of programming, used to develop new systems.

1st GL (First Generation Language) - Machine Language (ML)

• Pure machine code (machine language).
• Uses binary coded instructions (Zeros and Ones).
• Machine dependent.
• Drawbacks: Code cannot be easily exported, difficult to edit and update, must be rewritten for different systems.

2nd GL (Second Generation Language) - Assembly Language (AL)

• Uses symbolic coded instructions.
• Uses some English-like phrases (e.g., ADD, SUB).
• Machine dependent.
• Problem: Requires extensive programming knowledge, time-consuming for large programs, not machine-independent.

3rd GL (Third Generation Language) - Higher Level Languages (HLL)

• Called "high-level" programming languages.
• Uses statements close to English and arithmetic notations.
• Brought programmer-friendly features: loops, conditionals, classes.
• One line of 3GL code can produce many lines of object (machine) code, saving time.
• Platform independent: code written for one system can work on another.
• Requires a Compiler or an Interpreter to convert to machine language.
• Examples: C, C++, Python, Java.

4th GL (Fourth Generation Language) - Very High Level Languages

• Designed to be closer to natural human language than other HLLs.
• Accessible to people without formal programming training.
• Allows multiple common operations with a single programmer-entered command.
• Intended to be easier for users.
• Reduces programming effort, software development time, and cost.
• Uses a Compiler or an Interpreter.
• Examples: FoxPro, LINC, FOCUS, SQL, Applescript, VBScript, SPSS.

5th GL (Fifth Generation Language) - Natural Language

• Represents the next step in programming language development.
• Statements closely resemble human speech.
• Focuses on expert systems, artificial intelligence, and independently smart computer systems.
• Applications/Representations: Expert Systems, Vision Systems, Speech/Voice recognition, Handwriting recognition, Robotics (Intelligent robots), Machine Learning & sub-fields (Neural networks, deep-learning).

Programming Language Details

• A programming language is a set of written symbols that instructs computer hardware to perform specific tasks.
• Consists of a vocabulary and a set of rules (syntax) that the programmer must learn.
• Allows expressing data processing symbolically, without machine-specific details.
• Used to create programs that control machine behavior and express algorithms precisely.
• Made up of a series of statements that form instructions, telling the computer what to do.
• Popular Languages: Python, Java, C++, BASIC, Scratch.
• Languages differ (e.g., Python uses lowercase, BASIC uses uppercase for instructions).
• Most programming languages must be translated into machine code before execution.

Fundamentals of Programming

Programming involves activities such as:

• Analysis
• Developing
• Understanding
• Generating algorithms
• Verification of algorithm requirements (correctness, resource consumption)
• Implementation (coding) of algorithms in a target programming language

Basic Programming Elements

There are five basic programming elements:

1. Input-Output Instruction
2. Arithmetic Instruction
3. Conditional Instruction
4. Looping Instruction

Program Definition

• A program is a sequence of instructions a computer follows to solve a problem, written in a computer language.
• The process of collecting requirements, analyzing a problem, designing its solution, writing, and maintaining a computer program is called software development.
• Programs are made up of statements that the programming language understands.
• Each statement performs a specific task or instruction.

Common Statements and Purpose

Statement	Purpose
Print	Output a message on the screen
Input	Get data from the user
if...else	A decision
While	A loop controlled by a decision
For	A loop controlled by a counter
Def	Create a procedure or function

Software Development

• Programming is needed to turn ideas or business solutions into reality.
• Small changes can be implemented quickly with a streamlined process.
• Larger changes require a software development methodology to guide and manage the process, specifically the Systems Development Life Cycle (SDLC).

Software Development Life Cycle (SDLC)

• Definition: A conceptual model including policies and procedures for developing or altering systems throughout their life cycles. It applies standard business practices to building software applications.
• Aim: To produce high-quality software that meets or exceeds customer expectations, completes within time and cost estimates.
• Effective SDLC: Results in a high-quality system that meets customer expectations, completes on time/cost, and works effectively/efficiently within the current and planned IT infrastructure.

Phases of SDLC

SDLC is a systematic approach breaking down work into phases, used by analysts to develop systems. Core components recommended for all software development projects:

1. Preliminary Analysis: Requests are reviewed.
   • Deliverable: Feasibility analysis document.
2. Systems Analysis: If approved, determine system requirements for the new system.
   • Deliverable: Systems requirement document.
3. Systems Design: Converts system analysis requirements into system design document.
   • Deliverable: System design document.
4. Programming: Coding commences using design documents.
5. Testing: Ensures code functions according to requirements.
6. Implementation: Converting from old system to new system.
   • Training, documenting functions, and data conversion.
7. Maintenance: Support for reporting, prioritizing, and fixing bugs.

SDLC Models

A framework describing activities at each stage of a software development project, also known as "Software Development Process Models." Each model follows a unique series of phases for successful development.

Important SDLC Models discussed:

• Waterfall Model
• V-Model
• Structured Evolutionary Prototyping Model
• Rapid Application Model (RAD)
• Incremental Model
• Spiral Model
• Agile Models (e.g., Extreme Programming, Feature Driven Design, DSDM, Adaptive SDLC)

Waterfall Model

• Description: A linear sequential flow model. Each phase must be completed before the next begins.
  • Phases: Requirements → Design → Implementation → Test → Installation → Maintenance.
• Requirements: Defines needed information, function, behavior, performance, interfaces.
• Design: Data structures, software architecture, interface representations, algorithmic details.
• Implementation: Source code, database, user documentation, testing.
• Strengths:
  • Easy to understand and use.
  • Provides structure for 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.
• Deficiencies:
  • All requirements must be known upfront.
  • Deliverables for each phase are considered frozen, inhibiting flexibility.
  • Can give a false impression of progress.
  • Does not reflect problem-solving nature of software development (iterations).
  • Integration is one big bang at the end.
  • Little opportunity for customer to preview the system until late stages.
• When to use:
  • 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

• Description: A variant of the Waterfall model that emphasizes the verification and validation (V&V) of the product. Testing is planned in parallel with corresponding development phases.
• Steps:
  • Project & Requirements Planning (allocate resources) ↔ Production, Operation & Maintenance (enhancement, corrections)
  • Product Requirements & Specification Analysis (complete system spec) ↔ System & Acceptance Testing (check entire system in environment)
  • Architecture High-Level Design (defines how software fulfills design) ↔ Integration & Testing (check module interconnections)
  • Detailed Design (develop algorithms for components) ↔ Unit Testing (check each module)
  • Coding (transform algorithms into software)
• Strengths:
  • Emphasizes planning for V&V in early stages.
  • Each deliverable must be testable.
  • Project management can track progress by milestones.
  • Easy to use.
• 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:
  • Excellent choice for systems requiring high reliability (e.g., hospital patient control applications).
  • All requirements are known upfront.
  • When it can be modified to handle changing requirements beyond the analysis phase.
  • Solution and technology are known.

Structured Evolutionary Prototyping Model

• Description: Developers build a prototype during the requirements phase. This prototype is evaluated by end-users, who provide corrective feedback. Developers refine the prototype until the user is satisfied, then the code is brought to final product standards.
• Steps:
  • A preliminary project plan is developed.
  • An partial high-level paper model is created (source for partial requirements spec).
  • A prototype is built with basic and critical attributes.
  • The designer builds the database, user interface, and algorithmic functions.
  • The designer demonstrates the prototype, and the user evaluates for problems and suggests improvements.
  • This loop continues until the user is satisfied.
• Strengths:
  • Customers can "see" the system requirements as they are gathered.
  • Developers learn from customers.
  • Leads to a more accurate end product.
  • Unexpected requirements are accommodated.
  • Allows for flexible design and development.
  • Produces steady, visible signs of progress.
  • Interaction with the prototype stimulates awareness of additional needed functionality.
• Weaknesses:
  • Tendency to abandon structured program development for "code-and-fix".
  • Bad reputation for “quick-and-dirty" methods.
  • Overall maintainability may be overlooked.
  • The customer may want the prototype delivered prematurely.
  • Process may continue forever (scope creep).
• When to use:
  • Requirements are unstable or need clarification.
  • As the requirements clarification stage of a waterfall model.
  • To develop user interfaces.
  • For short-lived demonstrations.
  • For new, original development.
  • With the analysis and design portions of object-oriented development.

Rapid Application Model (RAD)

• Description: Emphasizes rapid development through iterative prototyping and incremental delivery, often utilizing automated tools.
• Phases:
  • Requirements planning: Workshop with structured discussion of business problems.
  • User description: Automated tools capture user information.
  • Construction: Productivity tools (code/screen generators) used within a time-box ("Do until done").
  • Cutover: System installation, user acceptance testing, user training.
• Strengths:
  • Reduced cycle time and improved productivity with fewer people (lower costs).
  • Time-box approach mitigates cost and schedule risk.
  • Customer involved throughout, minimizing risk of not achieving satisfaction.
  • Focus moves from documentation to code (WYSIWYG).
  • Uses modeling concepts to capture business, data, and process information.
• Weaknesses:
  • Accelerated development must give quick user responses.
  • 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 activities in an abbreviated timeframe.
• When to use:
  • Reasonably well-known requirements.
  • User involved throughout the life cycle.
  • Project can be time-boxed.
  • Functionality delivered in increments.
  • High performance is not required.
  • Low technical risks.
  • System can be modularized.

Incremental SDLC Model

• Description: Constructs a partial implementation of a total system and then slowly adds increased functionality. It prioritizes requirements and implements them in groups. Each subsequent release adds function until all designed functionality is implemented.
• Strengths:
  • Develops high-risk or major functions first.
  • Each release delivers an operational product.
  • Customer can respond to each build.
  • Uses "divide and conquer" for tasks.
  • Lowers initial delivery cost.
  • Initial product delivery is faster.
  • Customers get important functionality early.
  • Risk of changing requirements is reduced.
• Weaknesses:
  • Requires good planning and design.
  • Requires early definition of a complete and fully functional system for defining increments.
  • Well-defined module interfaces are required (some developed long before others).
  • Total cost of the complete system is not necessarily lower.
• When to use:
  • Risk, funding, schedule, program complexity, or need for early realization of benefits.
  • Most requirements are known upfront but expected to evolve over time.
  • A need to get basic functionality to the market early.
  • Projects with lengthy development schedules.
  • A project with new technology.

Spiral SDLC Model

• Description: 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 Activities:
  • Determine objectives, alternatives, constraints: Define functionality, performance, hardware/software interface, critical success factors. Consider alternatives (build, reuse, buy, sub-contract) and constraints (cost, schedule, interface).
  • Evaluate alternatives; Identify, resolve risks: Study alternatives relative to objectives and constraints. Identify risks (e.g., lack of experience, new technology, tight schedules, poor process) and resolve them (e.g., evaluate potential financial loss).
  • Develop next-level product: Typical activities include creating a design, reviewing design, developing code, inspecting code, and testing the product.
  • Plan next phase: Typical activities include developing a project plan, configuration management plan, test plan, and installation plan.
• Strengths:
  • Provides early indication of insurmountable risks without much cost.
  • Users see the system early due to rapid prototyping tools.
  • Critical high-risk functions are developed first.
  • The design does not have to be perfect initially.
  • Users can be closely tied to all lifecycle steps.
  • Early and frequent feedback from users.
  • Cumulative costs are assessed frequently.
• Weaknesses:
  • Time spent evaluating risks can be too large for small or low-risk projects.
  • Time spent planning, resetting objectives, 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.
• When to use:
  • When creation of a prototype is appropriate.
  • When costs and risk evaluation are important.
  • For medium to high-risk projects.
  • Long-term project commitment is unwise due to potential economic changes.
  • Users are unsure of their needs.
  • Requirements are complex.
  • New product line development.
  • Significant changes are expected (research and exploration).

Agile SDLC's

• Characteristics: Speed up or bypass one or more life cycle phases, usually less formal, reduced scope, used for time-critical applications, employed in organizations with 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 Unified 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 the project.
• Communication among teammates is primarily done with code.
• Life cycle and behavior of complex objects are 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 architect meetings with domain experts and developers.
  2. Build a features list: Identify all features supporting requirements, functionally decomposed into Business Activities steps within Subject Areas. Features are functions developed in two weeks, expressed as (e.g., "Calculate the total of a sale").
  3. Plan by feature: Development staff plans the development sequence of features.
  4. Design by feature: The team produces sequence diagrams for selected features.
  5. Build by feature: The team writes and tests the code.

Dynamic Systems Development Method (DSDM)

• Applies a framework for RAD and short timeframes.
• Follows the 80/20 rule: the majority of requirements can be delivered in a relatively short amount of time.
• Principles:
  1. Active user involvement (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.
• Lifecycle: Feasibility study, Business study, Functional model iteration (including risk analysis and time-box plan), Design and build iteration, Implementation.

Adaptive SDLC

• Combines RAD with software engineering best practices.
• Steps:
  1. Project initialization (determine project intent).
  2. Determine the project time-box (estimate duration).
  3. Determine optimal number of cycles and 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

• No single model fits all projects.
• If a perfect fit doesn't exist, select the closest model and modify it as needed.
• Projects should consider risk; for example, a full spiral model might be too much, so start with spiral elements and pare it down.
• For projects with serious reliability issues but delivered in increments, combine an incremental model with a V-shaped model.
• Each team must pick or customize an SDLC model to fit its specific project.

Quality

• Definition: The degree to which the software satisfies stated and implied requirements.
• Aspects of Quality:
  • Absence of system crashes.
  • Correspondence between the software and the users' expectations.
  • Performance to specified requirements.
• Importance: 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.
• Elements to consider in the plan:
  • Defect tracing: Keeps track of each defect found, its source, when detected, resolved, and how.
  • 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 already integrated code.
  • System testing: Execution of the software to find defects.

Next Lecture: Week 4

• Concept & properties of Algorithm
• Role of Algorithm in problem solving process
• Design of Algorithms
• Pseudocode
• Flowcharting