Chapter 1, Introduction to Software Engineering - PowerPoint PPT Presentation

Loading...

PPT – Chapter 1, Introduction to Software Engineering PowerPoint presentation | free to download - id: 1e121-NDdiY



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Chapter 1, Introduction to Software Engineering

Description:

You cheat if you do not acknowledge the contribution made by others. ... Source Code Depot ... Central Tariff ... – PowerPoint PPT presentation

Number of Views:99
Avg rating:3.0/5.0
Slides: 34
Provided by: bernd182
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com