SaaS - part I

Engineering Software Vs Engineering Hardware

So many disasters in Software development compared to HW disasters. Cost of upgrade: Very expensive in HW that's why HW designs must be finished (bugs fixed) before manufactured and shipped.
Legacy code  is old SW that continues responding to customer need and you should deal with, but is difficult to maintain and evolve as it's writing with old fashion in software development.
Beautiful code meets customer need and is easily to evolve.

Development processes: Waterfall vs. Agile

Waterfall life-cycle "Big design Up front" very used in HW, that's why used later in SW:

1. Requirement analysis and specification: meet with customers first and write down his needs
2. Architectural design
3. Implementation and Integration
4. Verification
5. Operation and maintenance

Each step can be done by different way but in a sequence way: complete current phase then go to next one.
Agile manifesto: continuous improvement instead of long phases, incomplete prototype but with continuous improvement.

1. Individuals & interactions over processes & tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation 
4. Responding to changes over following a plan

Assurance

• Verification (mostly used in HW) answers the question Did you build the thing right? Did you meet the specification?
• Validation (mostly used in SW) answers the question Did you build the right thing? Is this what the customer wants? Is the specification correct?

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

1. Unit test: single method does what was expected
2. Module or functional test: across individual units
3. Integration test: interfaces between units have consistent assumptions (communicate correctly)
4. System or acceptance test: integrated program meets its specifications 

 In agile development tests are writing before code you wish you had is actually writing. This is what we also cal TDD (Test Driven Development) or Debugging Sucks Testing Rocks.

Productivity

According to Moore's law HW designs are getting bigger (more transistors, memory) and thus lead to bigger SW designs. To improve productivity in HW and SW we come up with following techniques:

• Clarity via conciseness: write readable code, good syntax (bad one is hard to read), raise the level of abstraction (memory management, scripting languages, meta-programming),
• Synthesis: instead of doing it your self write tools that generate it for you (code generation)
• Reuse of other tools built by other people, don't re-invent the wheel, reuse code (functions and procedures, Std libraries, OOP, Design Patterns) 
• Automation and tools: automated things to replace tedious manual things (e.g. make, cucumber, RSpec)

DRY (Don't Repeat Yourself) don't want to find many places to apply same repair, don't copy and paste code.

Software as a Service (SaaS) 

Traditional SW are binary code installed and runs on local machine in a wholly client fashion. In contrast, SaaS delivers SW & data as service over the Internet via thin/universal program (e.g. browser) running locally.
All traditional SW will be running in cloud in a SaaS way in the few coming years. Why?

• No install worries about HW capabilities, OS
• No worries about data losses (everything in the cloud)
• Easy for group to share and interact with same data
• One copy of SW, controlled HW environment: no compatibility hassless, simplifies upgrades (no upgrade request sent to users)

Perfect match for SaaS, Agile and Rails as frequent upgrades matches Agile lifecycle, many framework for Agile/SaaS, Rails (was used by twitter in its beginning).

SOA (Service-Oriented Architecture) 

SOA is SW architecture where all components are designed as services instead of having a single monolithic running program (silo program). An application is just a combination of services.

SOA makes it easier to create new apps and customizing apps (e.g. choose a better service).

An example of an SOA architecture is depicted in following figure.

An SOA architecture

Cloud computing

SaaS demands on infrastructure include:

• Communication: allows customers to interact with service
• Scalability: fluctuations in demand during new services to add users rapidly
• Dependability: service and communication continuously available 24x7

How these challenges were addressed in past years: 

1. Clusters are commodity computers connected by commodity Ethernet switches. They are more scalable and cheaper than conventional servers. Dependability is guarantee via extensive redundancy of resources.
2. Warehouse Scale Computers: economies of scale pushed down cost of largest data-centers, traditional centers utilized 10 to 20%, the idea of making profit by offering pay-as-you-go use at less than your costs for as many computers as you need.
3. Utility computing/public cloud computing: offers computing/ storage/ communication with a low cost, as many computers as you want (illusion of unlimited resources), e.g. Google App Engine, Amazon Web Service, Microsoft Azure. 

Fallacies and Pitfalls

Fallacy: if a SW project is falling behind schedule, catch up by adding people. Actually, adding new people make it worst as more communication time is needed, and some time is also needed for these people to learn about the project.

Pitfall: is about ignoring the cost of software design and test.  

Is cost ~ no cost of manufacturing software / data same rationale ? no one should pay for development, just for manufacturing?

SW engineering is more than programming: long lasting / evolvable SW vs. short life of HW led to different development processes.

Software engineering is more than programming

References

It is recommended to read Engineering Long-Lasting Software: An Agile Approach Using SaaS and Cloud Computing to learn more about software engineering through a SaaS approach. Also you may follow Berkeley SaaS course at WebCast. Additional resources can be found at CS169

SaaS book