ece450 software engineering ii n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
ECE450 – Software Engineering II PowerPoint Presentation
Download Presentation
ECE450 – Software Engineering II

Loading in 2 Seconds...

play fullscreen
1 / 22

ECE450 – Software Engineering II - PowerPoint PPT Presentation


  • 213 Views
  • Uploaded on

ECE450 – Software Engineering II. Today: Lifecycles and Methodologies. Lifecycle of Software Projects. Lifecycle models are useful to compare project management strategies in abstract terms Birds-eye view strategy Detect strengths and weaknesses ... but reality is always more messy.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

ECE450 – Software Engineering II


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
ece450 software engineering ii

ECE450 – Software Engineering II

Today: Lifecycles and Methodologies

ECE450 - Software Engineering II

lifecycle of software projects
Lifecycle of Software Projects
  • Lifecycle models are useful to compare project management strategies in abstract terms
    • Birds-eye view strategy
    • Detect strengths and weaknesses
    • ... but reality is always more messy

ECE450 - Software Engineering II

waterfall model material adapted from steve easterbrook

perceived

need

requirements

design

code

test

integrate

Waterfall Modelmaterial adapted from Steve Easterbrook
  • View of development:
    • A process of stepwise refinement
    • High-level management view
  • Problems:
    • Static view of requirements (ignores volatility)
    • Lack of user involvement once spec is written
    • Unrealistic separation of spec from design
    • Doesn’t accomodate prototyping, reuse

ECE450 - Software Engineering II

v model material adapted from steve easterbrook

system

requirements

system

integration

Level of abstraction

software

requirements

acceptance

test

preliminary

design

software

integration

“test

and integrate”

“analyze and design”

detailed

design

component

test

code and

debug

unit

test

time

V Modelmaterial adapted from Steve Easterbrook

ECE450 - Software Engineering II

prototyping model material adapted from steve easterbrook
Prototyping Modelmaterial adapted from Steve Easterbrook
  • Prototyping is used for:
    • Understanding the requirements for the user interface
    • Examining feasibility of a proposed design approach
    • Exploring system performance issues
  • Problems
    • Users treat the prototype as the solution
    • A prototype is only a partial specification

ECE450 - Software Engineering II

phased models material adapted from steve easterbrook

design

design

design

design

code

code

code

code

test

test

test

test

integrate

integrate

integrate

integrate

O&M

O&M

O&M

O&M

Release 1

Incremental development

(each release adds more functionality)

Requirements

release 2

release 3

release 4

version 1

reqts

reqts

design

design

code

code

test

test

integrate

integrate

O&M

O&M

lessons learnt

version 2

lessons learnt

Evolutionary development

(each version incorporates new requirements)

version 3

reqts

design

code

test

integrate

Phased Modelsmaterial adapted from Steve Easterbrook

ECE450 - Software Engineering II

spiral model material adapted from steve easterbrook

Determine goals,

alternatives,

constraints

Evaluate

alternatives

and risks

constraints4

risk analysis4

constraints3

risk analysis3

Constr-

aints2

alternatives4

risk

analysis2

alternatives3

Altern-

atives2

alternatives

constraints

risk

analysis1

budget4

budget3

budget2

budget1

prototype1

prototype2

prototype3

prototype4

concept of

operation

software

requirements

detailed

design

requirements,

lifecycle plan

software

design

development plan

validated

requirements

code

integration and test plan

validated,

verified design

unit

test

Plan

Develop

and

test

system

test

acceptance

test

implementation plan

Spiral Modelmaterial adapted from Steve Easterbrook

ECE450 - Software Engineering II

agile model xp material adapted from steve easterbrook

Collect

User stories

code

Planning

game

Each cycle:approx 2 weeks

Release

integrate

test

Write test

cases

Agile Model (XP)material adapted from Steve Easterbrook

ECE450 - Software Engineering II

project lifecycle choices
Project lifecycle choices
  • Which lifecycle model to choose?
    • First of all, CHOOSE ONE!
      • Too many projects drift aimlessly without this kind of strategy
    • Second, if possible, AVOID WATERFALL
      • Most derided, error-prone lifecycle
      • Though still the lifecycle of choice in many corporations
    • Third, prototypes and iterations are good for you
      • Sanity checks
      • Almost never a waste of time/resources
    • Fourth, choose based on context and convenience

ECE450 - Software Engineering II

software methodologies
Software Methodologies
  • Reminder: A lifecycle is an abstract description of the life of a project
  • A methodology is a set of techniques that work well together
  • Lifecycles != Methodologies
    • Methodologies are usually (but not exclusively) built upon a lifecycle strategy

ECE450 - Software Engineering II

methodology types
Methodology Types
  • Main distinction: Sturdy vs. Agile
  • Key difference is how they handle uncertainty
    • Sturdyapproaches attempt to minimize the amount of uncertainty
      • Planning, risk prevention
    • Agile approaches attempt to minimize the impact of uncertainty
      • Adaptability, incremental processes

ECE450 - Software Engineering II

slide12
CMM
  • CMM: Capability Maturity Model
    • (now CMMI, where “I” stands for “integration”)
    • Developed by Watts Humphrey and the Software Engineering Institute (SEI) at CMU
    • Five levels
    • Certification process
      • Companies are evaluated as “CMM level 3”, for example
    • Mirrors Total Quality Management approaches

ECE450 - Software Engineering II

cmm cont
CMM (cont)
  • Pros:
    • Proven techniques
    • Self-sustained process
    • Required for some software contracts
  • Cons:
    • Fear of taking risks
    • Not popular among employees nor stellar companies
    • Doesn’t get more rigid than this!
      • Unless you go for ISO

ECE450 - Software Engineering II

cmm variants tsp and psp
CMM variants:TSP and PSP
  • TSP: Team Software Process
    • Your company isn’t keen on the CMM?
      • You can still embrace its processes at the team level
      • Same recipe as CMM, but in smaller scale
  • PSP: Personal Software Process
    • No, not PlayStation Portable!
    • Same story as TSP, on an individual scale
      • “A Discipline for Software Engineering”, Humphrey
    • Worth reading and doing the exercises, at least for self-awareness

ECE450 - Software Engineering II

cleanroom
Cleanroom
  • Best realization of “software engineering is formal methods” concept
    • Main idea: Don’t let the bugs in in the first place
      • To be added to product, piece of code must be proven correct
  • Pros:
    • Very high-quality software
    • Optimal for mission-critical projects
  • Cons:
    • Slow, not cost-effective
    • Good luck finding trained people

ECE450 - Software Engineering II

slide16
RUP
  • RUP: Rational Unified Process
    • Propietary process, IBM
    • Characterized by use of UML (Unified Modelling Language)
    • Feels like a matrix evolution on the waterfall model
      • “Phases” and “Disciplines”

ECE450 - Software Engineering II

rup cont
RUP (cont)
  • Pros:
    • More relaxed, though still “sturdy” approach to software projects
    • Popular in some mid-large software companies
    • Discards naive view of waterfall models
  • Cons:
    • Need to train people in new modelling skills
    • Controversy on cost-effectiveness of analysis and modelling
    • Doesn’t work well in changing environments

ECE450 - Software Engineering II

slide18
XP
  • XP = eXtreme Programming
    • Yes, terrible name
    • Intuition: Requirements changes are inevitable; emphasize adaptability
    • Practices:
      • User Stories
      • Planning Game
      • System Metaphor
      • Test-Driven Development
      • Small Releases
      • Pair Programming

ECE450 - Software Engineering II

xp cont
XP (cont)
  • The most successful of the agile methodologies
    • Though it’s debatable whether people that say they follow XP really are doing so
  • Pros:
    • Little spending in initial stages, results appear early
    • Change is expected, software adapts faster
    • Short feedback loops
  • Cons:
    • No time spent in analysis may mean lots of rework later on
    • No clear end in sight, project may continue forever
    • Pair programming feels awkward for most

ECE450 - Software Engineering II

scrum
SCRUM
  • An agile, lightweight “methodology” alternative

ECE450 - Software Engineering II

scrum cont
SCRUM (cont)
  • Pros:
    • Just about the easiest “methodology” to implement
    • Spends little developer time in documentation and meetings
    • 15-minute daily meetings are a great practice
  • Cons:
    • Not every customer is agreeable
    • Difficulties of scale
    • Long-term planning concerns

ECE450 - Software Engineering II

methodology choices
Methodology choices
  • THEY ALL WORK
    • Really!
    • They provide a framework for your project plans
    • But you need to be committed to make it work
  • Choice depends on personal/company/customer preference
  • What about Open Source projects?

ECE450 - Software Engineering II