SaaS Introduction—-coursera

Reference Book: <<Engineering long-lasting software>>

http://saasbook.info

 

Chapter One Engineering Software is Different from Engineering Hardware

https://www.coursera.org/saas/lecture/preview

1.1-1.2 - Introduction - Engineering Software is Different from Engineering Hardware

 

Why so man SW disasters and no HW disaters?

Ariane 5 rocket explosion

Therac-25 lethal radiation overdose

Mars Climate Orbiter disintegration

FBI Virtual Case File project abandonment

 

Independent Product vs Continuous Improvement

Cose of field upgrade

HW=∞

HW designs must be finished before manufactured and shipped

Bugs: Return HW (lose if many returns)

SW=0

Expect SW gets better over time

Bugs: Wait for upgrade

HW decays, SW long lasting

Legacy SW vs Beautiful SW

Legacy code: old SW that continues to meet customers' needs, but difficult to evolve due to design inelegance or antiquated technology

60% SW maintenance costs adding new functionality to legacy SW

17% for fixing bugs

Beautiful code: meets customers' needs and easy to evolve

 

 

1.3 Development Processes: Waterfall vs. Agile

 

Waterfall: Big Design Up Front

Requirements analysis and specification

Architectural design

Implementation and integration

Verification

Operation and maintenance

Complete one phase before start next one

Waterfall process works well for software with specs that won't change,

But often when customer sees result, wants big changes

But often after build first one, developers learn right way they should have built it

 

    " Plan to throw one [Implementation] away, you will, anyhow."----Fred Brooks, Jr.

    If a problem has no solution, it may not be a problem, but a fact, not to be solved, but to be coped with over time.    ----Shimon Peres

 

Agile Manifesto 2001

 

    "We are uncovering better ways of developing SW by doing it and helping others do it. Through this work we have come to value

• Individuals and interactions over processes & tools
  
• Working software over comprehensive documentation
  
• Customers collaboration over contract negotiation
  
• Responding to change over following a plan
  

  That is, while there is a value in the items on the right, we value the items on the left more."

   

  Agile lifecycle

• Embraces change as a fact of life: continuous improvement vs. phases
  
• Developers continuously refine working but incomplete prototype until customers happy, with customer feedback on each iteration ( every 2 weeks)
  
• Agile emphasize Test-Driven Development (TDD) to reduce mistakes, User Stories to reach agreement and validate customer requirements, Velocity to measure progress
  

1.4 Assurance

Verification: Did you build the thing right? Meet the specification?

Validation: Did you build the right thing? Is this what the customer wants? Is the specification correct?

Hardware focus generally verification

Software focus generally validation

 

Testing

 

Exhaustive testing infeasible

Divide and conquer: perform different tests at different phases of SW development

• Upper level doesn't redo tests of lower level
  
• System or acceptance test: integrated program meets its specifications
  
• Integration test: interfaces between units have consistent assumptions, communicate correctly
  
• Module or functional test: across individual units
  
• Unit Test: Single method does what was expected
  

 

More testing:

Coverage

Regression Testing

Continuous Integration Testing

Agile=> Test Driven Design: write tests before you write the code

 

Limits of Testing: Program testing can be used to show the presence of bugs, but never to show their absence! ( Edsger W. Dijkstra )

 

Formal Methods

Start with formal specification & prove program behavior follows spec. Options:

    Human does proof

    Computer via automatic theorem proving

    Computer via model checking

    Computationally expensive, so use only if

• Small, fixed function
  
• Expensive to repair, very hard to test
  
• E.g., network protocols, safety critical SW
  

 

1.5 Productivity

Moore's Law => 2X transistors/18 months

• HW designs get bigger
  
• Faster processers and bigger memories
  
• SW designs get bigger
  
• Must improve HW & SW productivity
  

 

Techniques

1. Clarity via conciseness
   
   1. Shorter and easier to read
      
   2. Raise the level of abstraction
      
2. Synthesis
   
3. Reuse
   
   1. Procedures and functions
      
   2. Standardized libraries
      
   3. Object oriented programming
      
   4. Design patterns
      
4. Automation and Tools
   

 

Don't Repeat Yourself (DRY)

Don't copy and paste code

1.6 Software as a Service

SaaS: delivers SW and data as service over internet via thin program (e.g., browser)

 

Reasons for SaaS:

• No install worries about HW capability, OS
  
• No worries about data loss
  
• Easy for groups to interact with same data
  
• If data is large or changed frequently, simpler to keep 1 copy at central site
  
• 1 copy of SW, controlled HW environment => no compatibility hassles for developers
  
• 1 copy => simplifies upgrade for developers and no user upgrade requests
  

 

SaaS Loves Agile & Rail

• Frequent upgrades matches Agile lifecycle
  
• Many frameworks for Agile/SaaS
  
• This course use Ruby on Rails