[INF43] Lecture 17 Process part 3

[INF43] Lecture 17 Process part 3

软件工程 SoftwareEngineering


@ZYX 写于2020年06月09日

XP Model

  1. Always create tests as early as possible, especially before coding
  2. Do as many development activities in pairs as possible
  3. Test as often as possible(continuous testing)
  4. Refactor all code
    • 改善代码质量,但不改变代码功能
  5. Involve the customer as much as possible

其他特征

  1. Open space office
  2. All pair programming
  3. every one has to learn code standard
    • then they can communicate effectively
(更多…)
           
[INF43] Lecture 15 Process Model part 2

[INF43] Lecture 15 Process Model part 2

软件工程 SoftwareEngineering


@ZYX 写于2020年06月02日

Spiral

  • Strengths
    • Good for new projects with uncertain, complex requirements
    • Riskiest parts get developed first
  • Weaknesses
    • Developers have to be competent at risk analysis
    • “End of project” may not be known

Rational Unified Process

  1. Use case driven
  2. Architecture centric
  3. Iterative and incremental
    • Strengths
    • Risk-driven, incremental
    • Lots of tool support
    • Provides a lot of guidance
    • Weaknesses
    • Complicated (need special expertise to implement it)
           
[INF43] Lecture 15 Pr

[INF43] Lecture 15 Pr

软件工程 SoftwareEngineering


@ZYX

Process

Process are rememdies

  1. Process can help but not silver bullet

What is model

  1. an ideal version of process: an ideal simplified representation

What is model for

  1. see ppt

Software Life Cycle Models

Models

Build-and-Fix

  1. Simple
    • Strength
    • Good for small programs that do not require much maintenance or many developers
    • Weaknesses
    • Not rigorous enough for non-trivial projects

Waterfall

  1. Very linear and very sequential
  2. Very ideal: all the requirements are written at the beginning, nothing will change
  3. Can create a lot of documentation
    • for the programs that are highly regulated like Space
    • Strength
    • Promotes understanding of requirements first
    • Disciplined, rigorous, formal
    • Lots of documentation
    • Good for projects with well-understood requirements that are unlikely to change
    • Provided a starting point for other software process models
    • Weakness
    • Rigid, not amenable to change
    • Limited user input
    • Bad for projects with any ambiguity in requirements or technology
    • Often run out of time for testing
    • “The waterfall model amounts to a pledge by all parties not to learn anything while doing the actual work.”

Rapid Prototyping

  1. “People don’t know what they want until they see what they don’t want.” – Humphrey’s Law
  2. “People don’t know what they want until you show it to them.” – Steve Jobs

Incremental

  1. Software becomes more complex as the time going
           
[INF43] Lecture 14 Testing part 4

[INF43] Lecture 14 Testing part 4

软件工程 SoftwareEngineering


@ZYX 写于2020年05月26日

White box testing

  • Use source code to derive test cases
    • Build a graph model of the system
    • State test cases in terms of graph coverage
  • Choose test cases that guarantee different types of coverage
    1. Node/statement coverage
    2. Edge/branch coverage
    3. Loop coverage
    4. Condition coverage
    5. Path coverage
(更多…)
           
[INF43] Lecture 13 Testing part3

[INF43] Lecture 13 Testing part3

软件工程 SoftwareEngineering


@ZYX

Two overall testing approaches

  1. Black box testing
    1. Specification-based testing
      1. give input and use testing oracle to check whether output is success
  2. White box testing
    1. structural-based testing
(更多…)
           
[INF43] Lecture 12 Testing part2

[INF43] Lecture 12 Testing part2

软件工程 SoftwareEngineering


@ZYX 写于2020年05月19日

Testing curve

Ways to choose test cases

  1. Intuition
  2. specification black
    1. know something what should they behaved then write the tests
  3. code (white-box testing)
    1. make sure the every line of code works
  4. Existing test cases (regression test)
    1. after making some changes, rerun the previous tests to make sure they can pass
  5. Faults
    1. based on experience, test the area that are likely to have bugs
(更多…)
           
[INF43] Lecture 11 Testing part 1

[INF43] Lecture 11 Testing part 1

软件工程 SoftwareEngineering


@ZYX

Failures

  1. Boeing 737
    1. Safety doesn't come first, money comes first
    2. do not modify hardware problem but software because it is cheaper (but not safer)
    3. Do not provide ways for human interven, and assume software is always right
  2. Toyota "Unintended Acceleration"
    1. Spaghetti code
      1. no seperation of concern
      2. high cohesion and low coupling
    2. Untestable and unfixable
      1. fix one bug then create one bug
    3. No peer review
    4. Throw away errors but no addressing
    5. No standard safety check (更多…)
           
[INF43] Lecture 10 Usability and software failure

[INF43] Lecture 10 Usability and software failure

软件工程 SoftwareEngineering


@ZYX 写于2020年05月12日

Interview and obeservation

  1. tacit knowledge: cannot be desribed

Personas

  1. the purpose of these are for you to understand who your users are and you can use them in a couple of different places.
  2. So you create these personas by you need to do some research, a lot of times it's talking to your customer. And maybe doing some market research about what types of users, there are similar applications and you want to try to find patterns in those usages and create these user groups.
  3. Casual User & Poweful User
    1. Casual User 对产品的需求度不高
    2. Powerful User 对产品需求度很高,而且会用所有functions
(更多…)
           
已到首页—下一页>>