Chapter 1, Introduction to Software Engineering

1
Chapter 1,Introduction to Software Engineering

2
Course format

• A Single Semester Course
• Lectures Theoretical foundations and background
• Project Learn how to apply them in practice
• Lectures and Project work are interleaved
• Labs and Assignments complement lectures and the
  team project
• A Single Project Course
• Everybody is working on the same project
• Cheating Rule for CS3013
• You cheat if you do not acknowledge the
  contribution made by others.

3
Lecture Overview

• Introduction
• Objectives of Course
• Project
• e-Textbook System Problem Statement
• Top Level Design
• Syllabus
• Introduction of People
• Administrative Matters
• Software Engineering Overview
• A UML class model of software engineering
• Activities
• Ticket distributor example

4
Objectives of this course

• Acquire technical knowledge
• Understand difference between program and
  software product
• Be able to reconstruct the analysis and design of
  an existing software system
• Be able to design and implement a subsystem that
  will be part of a larger system
• Acquire managerial knowledge
• produce a high quality software system within
  budget time
• while dealing with complexity and change

5
Emphasis is on team-work

• Participate in collaborative design
• Work as a member of a project team, assuming
  various roles
• Create and follow a project and test plan
• Create the full range of documents associated
  with a software product
• Complete a project on time

6
How can we accomplish this?

• Course Project
• e-Textbook online used textbook auction web site
• The 4 Rs
• Real Problem University students want an easy
  way to find used textbooks to buy as well as a
  way to auction off their own used textbooks (that
  they no longer need)
• Real Client You
• Real Data All textbooks purchased for courses at
  UNB and Saint Thomas
• Real Deadline April 12, 2001

7
Assumptions and Requirements for this Class

• Assumption
• You are proficient in a programming language
  (Java preferred), but have no experience in
  analysis or design of a system
• You have access to a Web Browser
• Course Homepage http//www.cs.unb.ca/profs/nicke
  rson/courses/CS3013ci.htm
• Requirements
• You have taken the prerequisite course CS2013
  Software Engineering I
• or
• You have practical experience with maintaining or
  developing a large software system

8
Project Goals

• Attempt to produce a web site with the e-Textbook
  auction site functionality
• Implementation of three major processes
• Handling registration of used textbooks for
  auction.
• Carrying out (in a secure fashion) the bidding
  process for textbooks.
• Keeping track of all registered users of the
  e-Textbook site.
• Demonstration of a conceptual prototype

9
Basic Software Architecture for e-Textbook Project
Auction a Textbook
Bidder
Add Textbook
Seller
Notification of Sale
Internet
Administrator
Add User
10
Teams

• e-Textbook will be developed in a team-based
  approach
• Each team will do the same e-Textbook project
• You will be member of one team of four to six
  people
• Teams will normally meet at least once per week
  during the lab session
• Team selection is done by project management and
  will be announced in class, Tuesday, January 16.
• Teams will be formed so that all team members
  have common lab times
• If you wish to be part of the same team, please
  assign one person to send me a suggested team
  list by e-mail

11
Acceptance Milestone

• The acceptance criteria are established in a
  dialog with the client during the requirements
  analysis phase
• The e-Textbook system will be delivered with the
  following artifacts on a CD-ROM
• Requirements Analysis Document
• System Design Document
• Object Design Document
• Test Manual
• Source Code Depot

12
If you need help

• Questions about Passwords, Logging into the
  network, Accessing the Home page
• UNB Computing Services help desk
  (helpdesk_at_unb.ca), 453-5199, room HD-11
• Questions about getting into the ITD414 lab
• Troy Cabel (tcabel_at_unb.ca), 452-6162, room GE-118
• Jeff Geddes (jgeddes_at_unb.ca), 452-6102, room
  GE-119
• Questions about the Course
• Brad Nickerson (bgn_at_unb.ca), 458-7278, room
  ITC304
• office hours Wednesdays, 1130 a.m. t o 1230,
  Fridays 330 to 500 p.m.

13
Software Engineering

• Software systems are complex
• Impossible to understand by a single person
• Many projects are never finished "vaporware"
• The problem is arbitrary complexity
• Definitions
• The establishment and use of sound engineering
  principles (methods) in order to obtain
  economically software that is reliable and works
  on real machines (Bauer, F. L. Software
  Engineering. Information Processing 71., 1972).
• Software engineering. (1) The application of a
  systematic, disciplined, quantifiable approach to
  the development, operation, and maintenance of
  software that is, the application of engineering
  to software. (2) The study of approaches as in
  (1) (IEEE Std 610-1990).
• Software engineering is the computer science
  discipline concerned with developing large
  applications. Software engineering covers not
  only the technical aspects of building software
  systems, but also management issues, such as
  directing programming teams, scheduling, and
  budgeting (WebReference Webopaedia ).
• Our definition
• Software Engineering means the construction of
  quality software with a limited budget and a
  given deadline in the context of constant change
• Emphasis is on both, on software and on
  engineering

14
Activities

• Modeling
• Problem-solving
• Knowledge Acquisition
• Rationale Driven
• Helps software engineers understand implications
  of change

15
Modeling

• Focusing relevant details at each development
  stage
• A model is an abstract representation of a system
  for answering questions about the system
• Real world system a set of phenomena
• Problem model a set of interdependent concepts
  describing those aspects of the real world
  relevant to the problem under consideration.
• Model of problem domain vs. model of solution
  domain
• OO methods Problem D. model Solution D. model
• Objects and relationships in problem domain
• Object and relationships in solution domain
  (extension from 1)
• Software Development identify and describe a
  system as a set of models to address the end
  users problem.

16
(No Transcript)
17
Problem Solving

• Software engineering is an engineering activity
• Rely on empirical methods to evaluate the
  benefits of different alternatives represented as
  models
• The engineering method
• 1. Formulate the problem (requirements
  elicitation and
• 2. Analyze the problem analysis)
• 3. Search for solutions
  (system design and
• 4. Decide on the appropriate solution object
  design)
• 5. Specify the solution (implementation)
• Activities experimentation, pattern reuse,
  incremental evolution, reviews of problem and
  solution models

18
Knowledge Acquisition

• In modeling application and solution domains
• Data collection
• Information organization
• Knowledge formalization
• Non-linear knowledge acquisition
• Single piece of data can invalidate complete
  models
• Linear software development process
• Waterfall model
• Non-linear software process
• Risk-based development
• develop higher risks first
• Issue-based development
• develop all issues in parallel

19
Rationale Driven

• Rationale of the system
• The context and rationale in which each design
  decision was made
• To be captured and understood by software
  engineer
• Represents a set of issue models with larger
  amount of information than the solution models
• Not explicit (without explicitly evaluating
  different alternatives)
• Enables software engineers to understand the
  implication of a proposed change when revising a
  decision.
• Rationale management

20
Software Engineering Concepts

• Participants and Roles
• Role
• a set of responsibilities
• associated with a set of tasks
• assigned to a participant
• typical roles end user, client, developer,
  project manager
• Participant
• any persons involved in the project
• plays certain role(s)
• Systems and Models
• System the underlying reality
• example ticket distributor for a train
• Model any abstraction of the reality
• example requirement, analysis, design,
  implementation models

21
Figure 1-1. Software engineering concepts,
depicted as a UML class diagram (OMG, 1998).

consumes
is produced by



22

• Work Products
• Artifact produced during development
• Internal work product
• for the projects internal consumption
• any artifact not in the contract or requested by
  the client
• example test plan
• Deliverable
• for the client
• defined prior to the start of the project and
  specified in the contract.
• Activities, Tasks, and Resources
• Activity or phases a set of tasks for a special
  purpose such as requirement elicitation
• Task an atomic unit of work in terms of
  management, to be assigned to a developer.
• Resources assets to be used to accomplish work.

23

• Goals, Requirements and Constraints
• Goals
• a high level principle to guide the project
• define the attributes of the system that are
  important
• primary goal and other goals of a project
• conflicting goals
• Functional requirements
• area of functionality that the system must
  support (e.g. provide the user with a paper copy
  of the ticketing information)
• Nonfunctional requirements
• operation of the system (e.g. response back to
  user in less than one second 99 of the time)
• examples performance, reliability, security
• Constraints
• interface with an existing computer system

24

• Notations, Methods, and Methodologies
• Notation
• a graphical or textual set of rules for
  representing a model
• Example UML for OO modeling, Z for system
  specification using sets
• Method
• A repeatable technique for solving a specific
  problem
• Example sorting algorithm, version control
• Methodology
• a collection of methods for solving a class of
  problems
• decompose software process into activities
• examples Unified software development process,
  Object Modeling Technique (OMT), Catalysis.

25
Software Engineering Development Activities

• Requirement elicitation (Client and Developer)
• The client and developers define the purpose of
  the system
• Result description of actors and use cases for
  functional requirement
• Example
• Use case name PurchaseOneWayTicket
• Participating actor Initialized by Traveler
• Entry condition 1. Traveler stands in front of
  the ticket distributor at a station
• Flow of events 2. Traveler selects the source
  and destination stations
• 3. TicketDistributor display the price of the
  ticket
• 4. Traveler inserts sufficient money
• 5. TicketDistributor issues the ticket and
  returns change
• Exit condition 6. Traveler holds a valid ticket
  and the change
• Special requirements If the transaction is not
  completed after 1 minute of inactivity,
  TicketDistributor returns all inserted money

26

• Nonfunctional requirements
• Reliability The ticket distributor should be
  available to traveler at least 95 of the time
• Performance The ticket distributor should
  provide feedback to the traveler within a second
  after the transaction has been selected.
• Analysis (Developer)
• produce a model of the system that is correct,
  complete, consistent, unambiguous, realistic, and
  verifiable.
• transform the use cases into an object model that
  completely describes the system
• discover ambiguities and inconsistencies

27
Figure 1-3. An object model for the ticket
distributor (UML class diagram). In the
PurchaseOneWayTicket use case, a Traveler
initiates a transaction that will result in a
Ticket. A Ticket is valid only for a specified
Zone. During the Transaction, the system tracks
the Balance due by counting the Coins and Bills
inserted.
valid for
results in
amount paid
28

• System Design (Developer)
• define the design goals
• decompose the system into smaller subsystems that
  can be realized by individual teams.
• Select strategies for building the system
• results
• strategy descriptions
• subsystem decomposition
• deployment diagram
• Object Design (developer)
• define custom objects to bridge the gap between
  the analysis model and the system design platform
• Implementation
• translate the object model into source code

29
Figure 1-4. A subsystem decomposition for the
TicketDistributor (UML class diagram, folders
represent subsystems, dashed lines represent
dependencies). The Traveler Interface subsystem
is responsible for collecting input from the
Traveler and providing feedback (e.g., display
ticket price, returning change). The Local Tariff
subsystem computes the price of different tickets
based on a local database. The Central Tariff
subsystem, located on a central computer,
maintains a reference copy of the tariff
database. An Updater subsystem is responsible for
updating the local databases at each
TicketDistributor through a network when ticket
prices change.
30
Managing Software Development

• Communication
• exchange models and documents
• report the status of work products
• provide feedback on the quality of work products
• raise and negotiate issues
• communicate decisions
• common convention and tool based
• Rationale management
• the problem addressed
• alternatives considered
• evaluation criteria used
• debate, consensus, and decision
• difficulty update and maintenance

31

• Testing
• find differences between the system and its
  models by execution with sample data
• Unit testing
• compare the object design model with each object
  and subsystem
• Integration testing
• compare the integrated subsystems with the system
  design
• System testing
• compare the system with the requirement model by
  running typical and exception cases

32

• Software Configuration Management
• the process that monitors and controls changes in
  work products
• Example changes
• requirement changes
• client new feature
• development new/improved understanding
• platform changes
• new technology available
• system changes
• fault and repair
• enable developer to track changes
• configuration items to be individually revised
• versions for evolution of configuration items and
  roll back
• enable developers to control change
• define baselines
• assess and approve increments from the baselines

33

• Project management
• oversight activities to ensure
• the delivery of a high-quality system on time and
  within budget
• plan and budget the project during negotiation
  with the client
• hire developers and organize them into teams
• monitor the status of the project
• intervene when deviations occur
• Software life Cycle
• A general model of the software development
  process