Software Lifecycle and Team Programming Arun Chauhan COMP 314 - - PowerPoint PPT Presentation

▶
software lifecycle and team programming
SMART_READER_LITE
LIVE PREVIEW

Software Lifecycle and Team Programming Arun Chauhan COMP 314 - - PowerPoint PPT Presentation

Dec 16, 2022 139 likes •838 views

Software Lifecycle and Team Programming Arun Chauhan COMP 314 Lecture 2 January 21, 2003 Recap of the Last Lecture Lecture 2: Software Lifecycle and Team Programming January 21, 2003 BFS 1 for each vertex v in V 2 color[v] = white 3

slide-1
SLIDE 1

Software Lifecycle and Team Programming

Arun Chauhan COMP 314

Lecture 2 January 21, 2003

slide-2
SLIDE 2

Recap of the Last Lecture

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-3
SLIDE 3

BFS

1 for each vertex v in V 2 color[v] = white 3 d[v] = INFINITY 4 p[v] = NULL 5 color[s] = gray 6 d[s] = 0 7 Queue.clear() 8 Queue.put(s) 9 while (!Queue.empty()) 10 v = Queue.get() 11 for each u adjacent to v 12 if (color[u] == white) 13 color[u] = gray 14 d[u] = d[v] + 1 15 p[u] = v 16 Queue.put(u) 17 color[v] = black

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-4
SLIDE 4

Lemmas

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-5
SLIDE 5

Lemmas

Lemma 1: Let G = (V, E) be a graph, and s ∈ V a vertex. Then, for any edge (u, v) ∈ E : b(s, v) ≤ b(s, u) + 1

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-6
SLIDE 6

Lemmas

Lemma 1: Let G = (V, E) be a graph, and s ∈ V a vertex. Then, for any edge (u, v) ∈ E : b(s, v) ≤ b(s, u) + 1 Lemma 2: Upon termination, the BFS algorithm computes d[v] for every vertex, and d[v] ≥ b(s, v).

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-7
SLIDE 7

Lemmas

Lemma 1: Let G = (V, E) be a graph, and s ∈ V a vertex. Then, for any edge (u, v) ∈ E : b(s, v) ≤ b(s, u) + 1 Lemma 2: Upon termination, the BFS algorithm computes d[v] for every vertex, and d[v] ≥ b(s, v). Lemma 3: At all times during the execution of BFS, the queue contains vertices (v1, v2, . . . vr) such that d[v1] ≤ d[v2] ≤ d[v3] . . . ≤ d[vr] AND d[vr] ≤ d[v1] + 1.

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-8
SLIDE 8

Lemmas

Lemma 1: Let G = (V, E) be a graph, and s ∈ V a vertex. Then, for any edge (u, v) ∈ E : b(s, v) ≤ b(s, u) + 1 Lemma 2: Upon termination, the BFS algorithm computes d[v] for every vertex, and d[v] ≥ b(s, v). Lemma 3: At all times during the execution of BFS, the queue contains vertices (v1, v2, . . . vr) such that d[v1] ≤ d[v2] ≤ d[v3] . . . ≤ d[vr] AND d[vr] ≤ d[v1] + 1. Corollary 4: If vertices u and v are enqueued during execution of BFS, and u is enqueued before v, then d[u] ≤ d[v].

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-9
SLIDE 9

Theorem

Theorem: Given G = (V, E) and source vertex s, the BFS algorithm discovers every vertex v reachable from s, and upon termination, d[v] = b(s, v). Moreover, for any vertex v reachable from s, one of the shortest paths from s to v is a path from s to p[v], followed by edge (p[v], v).

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-10
SLIDE 10

Lecture 2

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-11
SLIDE 11

What this Lecture is About

  • applied aspects of data-structures and algorithms
  • “software engineering”
  • issues in developing large software
  • techniques for managing software development
  • software lifecycle
  • project management
  • extreme programming

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-12
SLIDE 12

State of the Software

If software were an office building, it would be built by a thousand carpenters, electricians and plumbers. Without architects. Or blueprints. It would look spectacular, but inside, the elevators would fail regularly. Thieves would have unfettered access through open vents at street level. Tenants would need consultants to move in. They would discover that the doors unlock whenever someone brews a pot of coffee. The builders would provide a repair kit and promise that such idiosyncrasies would not exist in the next skyscraper they build (which, by the way, tenants will be forced to move into). Strangely, the tenants would be OK with all this. They’d tolerate the costs and the

  • ddly comforting rhythm of failure and repair that came to dominate their lives. If

someone asked, “Why do we put up with this building?” shoulders would be shrugged, hands tossed and sighs heaved. “That’s just how it is. Basically, buildings suck.” from an online article on idg.net

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-13
SLIDE 13

Does Software Really Suck?

  • slight exaggeration, but not far from the fact
  • examples of software failures abound
  • but, sofware companies still expect to make money!

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-14
SLIDE 14

Software Failures

Year 1900 Bug

In 1992, Mary from Winona, Minnesota, received an in- vitation to attend a kindergarten. Mary was 104 at that time.

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-15
SLIDE 15

Software Failures

Interface Misuse

On April 10, 1990, in London, an underground train left the station without its driver. The driver had taped the button that started the train, relying on the system that prevented the train from moving when doors were open. The train operator had left his train to close a door which was stuck. When the door was finally shut, the train simply left.

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-16
SLIDE 16

Software Failures

Late and Over Budget

In 1995, bugs in the automated luggage system of the new Denver International Airport caused suitcases to be chewed up. The airport opened 16 months late, $3.2 billion over-budget, with mostly manual luggage system.

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-17
SLIDE 17

Software Failures

On-Time Delivery

After 18 months of development, a $200 million system was delivered to a health insurance company in Wiscon- sin in 1984. However, the system did not work correctly; $60 million in overpayments were issued. The system took 3 years to fix.

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-18
SLIDE 18

Software Failures

Unnecessary Complexity

The C-17 cargo plane by McDonnel Douglas ran $500 million over budget because of problems with its avionics

  • software. The C-17 included 19 onboard computers, 80

microprocessors, and 6 different programming languages.

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-19
SLIDE 19

Lessons

  • we rely more and more on software in our daily lives
  • software mistakes are costly
  • software reliability is critical
  • software usability is very important
  • software projects are mostly ill-managed

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-20
SLIDE 20

Why Software Engineering?

  • software engineering coined in the late 1960s because:

Software developers were not able to set concrete objec- tives, predict the resources necessary to attain those ob- jectives, and manage the customers’ expectations. More

  • ften than not, the moon was promised, a lunar rover

built, and a pair of square wheels delivered.

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-21
SLIDE 21

Why Software Engineering?

  • software engineering coined in the late 1960s because:

Software developers were not able to set concrete objec- tives, predict the resources necessary to attain those ob- jectives, and manage the customers’ expectations. More

  • ften than not, the moon was promised, a lunar rover

built, and a pair of square wheels delivered.

  • Arguably, large pieces of software are the most

complicated entities ever created by humans!

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-22
SLIDE 22

What is Engineering?

  • well established engineering disciplines are

applications of natural sciences

  • engineering is a quick way to design objects
  • civil engineers have widely used “handbooks” to guide

construction

  • engineering is a collection of best practices
  • engineering is a collection of design patterns

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-23
SLIDE 23

Activities in a Large Project

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-24
SLIDE 24

Activities in a Large Project

  • modeling

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-25
SLIDE 25

Activities in a Large Project

  • modeling
  • problem solving

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-26
SLIDE 26

Activities in a Large Project

  • modeling
  • problem solving
  • knowledge acquisition

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-27
SLIDE 27

Activities in a Large Project

  • modeling
  • problem solving
  • knowledge acquisition
  • rationale management

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-28
SLIDE 28

Modeling with UML

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-29
SLIDE 29

Modeling With UML

  • functional model
  • UML use case models
  • functionality of the system from user’s point of view
  • object model
  • UML class diagrams
  • structure of a system in terms of objects, attributes,

associations, and operations

  • dynamic model
  • UML sequence diagrams, statechart diagrams, activity

diagrams

  • internal behavior of the system

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-30
SLIDE 30

Use Case Diagrams

ReadTime SetTime ChangeBattery SimpleWatch WatchRepairPerson WatchUser

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-31
SLIDE 31

Use Case Diagrams: Generalization

Authenticate Authenticate WithPassword Authenticate WithCard

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-32
SLIDE 32

Use Case Diagrams: Include

DepressClutch <<include>> <<include>> ChangeGearToReverse ChangeGearToFirst

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-33
SLIDE 33

Use Case Diagrams: Extend

EngineStalled <<extend>> ChangeGearToReverse ChangeGearToFirst <<extend>>

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-34
SLIDE 34

Class Diagrams

Battery SimpleWatch 1 1 1 2 1 2 1 1 PushButton Display Time

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-35
SLIDE 35

Class Diagrams: Aggregation

State PoliceStation PoliceOfficer County Township File Directory

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-36
SLIDE 36

Class Diagrams: Inheritance

Watch CalculatorWatch calculatorState EnterCalcMode() InputNumber(n) SetDate(d) date time

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-37
SLIDE 37

Class Diagrams: Instances

cW15:CalculatorWatch <<instanceOf>> <<instanceOf>> Watch CalculatorWatch sW1291:Watch

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-38
SLIDE 38

Sequence Diagrams

:WatchUser :SimpleWatch :Time :TimeZone pressButton2() getTime() GMTTime() GMTTime() getTimeDelta()

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-39
SLIDE 39

State Chart Diagrams

BlinkHours Increment Hours Increment Minutes Increment Seconds

button1&2pressed button1&2pressed button2pressed button2pressed button2pressed

button1pressed

button1pressed

StopBlinking BlinkSeconds BlinkMinutes

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-40
SLIDE 40

Software Life Cycle

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-41
SLIDE 41

Software Development: Simple View

Administrator End User Client <<include>> <<include>> Software development Problem definition System development System operation Project Manager Developer

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-42
SLIDE 42

Simple Activity Centric View

definition activity System development activity System

  • peration

activity Problem

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-43
SLIDE 43

Simple Entity Centric View

System specification Software Development document document Executable system document Lessons learned Market survey

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-44
SLIDE 44

Software Life Cycle: IEEE 1074

Software life cycle Process group Phase Work Product Task Resource Participant Time Money * * * * * *

consumes produces

Process Activity

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-45
SLIDE 45

Waterfall Model

Process Project Exploration Allocation Design Process Validation installation Processs Operation & Initiation Process Concept Process System Process Requirements Process Process Implementation Verification & Processs Support

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-46
SLIDE 46

V-Model

Operation Requirement Software Preliminary Design Detailed Design System Analysis System Elicitation Requirements Analysis Requirements Implementation Test Unit & Test Component Integration & Test Integration Acceptance Client

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-47
SLIDE 47

Other Models

  • Boehm’s Spiral Model
  • Sawtooth Model
  • Shark Tooth Model

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-48
SLIDE 48

Design Patterns in UML

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-49
SLIDE 49

Design Patterns

Composite * leaves Leaf Component

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-50
SLIDE 50

Design Patterns

Compiler Optimizer create() generateParseTree() Parser compile(s) CodeGenerator create() ParseTree create() Compiler getToken() Lexer

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-51
SLIDE 51

Extreme Programming

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-52
SLIDE 52

Extreme Programming

  • relatively new idea—barely 6 years old
  • suited to small projects, of 2-30 people
  • relaxes the heavyweight management in favor of

informality

  • software development process divided into four types
  • f activities
  • planning
  • designing
  • coding
  • testing

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-53
SLIDE 53

XP: Coding (simplified)

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-54
SLIDE 54

XP: Coding (simplified)

  • customer is always available

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-55
SLIDE 55

XP: Coding (simplified)

  • customer is always available
  • code formatted to standards
  • design patterns
  • best practices

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-56
SLIDE 56

XP: Coding (simplified)

  • customer is always available
  • code formatted to standards
  • design patterns
  • best practices
  • unit test coded first
  • unit tests also serve as documentation

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-57
SLIDE 57

XP: Coding (simplified)

  • customer is always available
  • code formatted to standards
  • design patterns
  • best practices
  • unit test coded first
  • unit tests also serve as documentation
  • pair programming
  • counter-intuitive, but works!

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-58
SLIDE 58

XP: Coding (simplified)

  • customer is always available
  • code formatted to standards
  • design patterns
  • best practices
  • unit test coded first
  • unit tests also serve as documentation
  • pair programming
  • counter-intuitive, but works!
  • collective code ownership

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-59
SLIDE 59

XP: Coding (simplified)

  • customer is always available
  • code formatted to standards
  • design patterns
  • best practices
  • unit test coded first
  • unit tests also serve as documentation
  • pair programming
  • counter-intuitive, but works!
  • collective code ownership
  • optimize last

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-60
SLIDE 60

Tools

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-61
SLIDE 61

Modern Tools

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-62
SLIDE 62

Modern Tools

  • project tools

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-63
SLIDE 63

Modern Tools

  • project tools
  • CASE tools

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-64
SLIDE 64

Modern Tools

  • project tools
  • CASE tools
  • project management tools
  • PERT charts (Program Evaluation Review Technique), also

called PERT / CRM (Critical Path Management)

  • Gantt charts
  • project management software

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-65
SLIDE 65

Modern Tools

  • project tools
  • CASE tools
  • project management tools
  • PERT charts (Program Evaluation Review Technique), also

called PERT / CRM (Critical Path Management)

  • Gantt charts
  • project management software
  • high-level languages

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-66
SLIDE 66

Modern Tools

  • project tools
  • CASE tools
  • project management tools
  • PERT charts (Program Evaluation Review Technique), also

called PERT / CRM (Critical Path Management)

  • Gantt charts
  • project management software
  • high-level languages
  • program development environments

Lecture 2: Software Lifecycle and Team Programming January 21, 2003

slide-67
SLIDE 67

Next Lecture: Back to Graphs

Lecture 2: Software Lifecycle and Team Programming January 21, 2003