document1

53
Software as a Product Paolo Ciancarini

Upload: majong-devjfu

Post on 10-May-2015

568 views

Category:

Technology


0 download

TRANSCRIPT

Page 1: Document1

Software as a Product

Paolo Ciancarini

Page 2: Document1

Agenda •  Software products •  The software industry •  Architectural and engineering issues

Page 3: Document1

Why is software important?

•  Software is a key component in the modern industry, especially in the innovative, emerging technologies

•  In the next few slides we report the Gartner hype cycle for the emerging technologies from 2005 to 2010

Page 4: Document1

Hype Cycle of emerging technologies (according to Gartner)

Page 5: Document1

Hype cycles 2005

Page 6: Document1

2006

Page 7: Document1

2007

Page 8: Document1

2008

Page 9: Document1

2009

Page 10: Document1

2010

Page 11: Document1

Discuss

Identify in the Gartner diagrams the technologies which are software-intensive

Page 12: Document1

Software is an industrial product The world sw industry increased its volume at 10% rates yearly

during the ‘90, and at 3% in 2001, now is back at 10%

Several technological innovations are based on software (eg. Cellular telephones, Mp3 devices and iTunes, etc.)

A cellular telephone includes 5+ MLOC (source Nokia) Windows XP includes 40+ MLOC (Windows 95: 11 MLOC)

The developments costs of a software increases with the square of its dimension in LOC [Berra-Meo 2001]

Page 13: Document1

The software industry

•  According to DataMonitor, the size of the worldwide software industry in 2008 was US$ 303.8 billion, an increase of 6.5% compared to 2007

•  Americas account for 42.6% of the global software market's value

•  In 2013, the global software market will have a value of US$ 457 billion, an increase of 50% since 2008

Page 14: Document1

Software

•  Good: product invisible, intangible, easily duplicated, very expensive to build

•  Component of a computer system: can be widely (re)used (off the shelf) or commissioned by a specific user

•  Abstract machine based on an abstract architecture

•  Service invoked via a well defined interface and based on a communication infrastructure

Page 15: Document1

Software components

•  COTS: “component off the shelf” •  Component based software

architectures •  Building software by integration •  Software component markets

– Enterprise Java Beans – Microsoft .NET

Page 16: Document1

Software: the product of a process

•  Many kinds of software products, many kinds of development processes

•  Study the process to improve the product

•  Examples of processes: waterfall, iterative, agile, extreme,…

•  Software development processes are software too

Page 17: Document1

Many kinds of software

•  Middleware •  Embedded •  Open source •  Web Services •  Mobile (eg. applet) •  Data mining (eg. Search engine) •  Agents •  Social software (eg. Web 2.0) •  Software Ecosystems •  …

Page 18: Document1

Embedded software •  Within only 30 years the amount of software in

cars went from 0 to more than 10,000,000 lines of code

•  More than 2000 individual functions are realized or controlled by software in premium cars, today

•  50-70% of the development costs of the software/hardware systems are software costs

•  (M.Broy, “Challenges in Automotive Software Engineering”, ICSE2006, pp33-42,2006)

Page 19: Document1

Embedded software

Page 20: Document1

Software as a service Service: the immaterial equivalent of a good

•  Software is a service at heart, albeit an automated one, but it is sold much like a manufactured good. Customers have to pay large sums of money up front, bear much of the risk that a program may not work as promised, and cannot readily switch vendors.

The Economist, 2003

Page 21: Document1

Service oriented architectures •  SOA compose different

services for complementary domains

•  They are often base on stacks of service layers

•  SOA services feature loose coupling that can be “orchestrated” according to some rules of “choreography”

Page 22: Document1

Software ecosystems

•  A software ecosystem is a set of businesses functioning as a unit and interacting with a shared market for software and services, together with relationships supported by a common technological platform

•  Eg: Apple Application Store

Page 23: Document1

Software architecture and engineering

Page 24: Document1

Software architecture •  The discipline of software architecture is centered on

the idea of reducing the design complexity of software systems through abstraction and separation of concerns

•  The discipline has developed a number of design styles and patterns that help in designing or integrating software intensive systems

•  However, it is hard to find sw architects who agree on the right way to architect a software system

•  Wrong decisions in crafting the software architecture are a major cause of project cancellation

Page 25: Document1

Software engineering

•  Software Engineering is a discipline studying the methods to produce software, the theories at their basis, and the tools effective to develop and measure the qualities of software systems

•  Software engineering deals with limited resources •  It is a discipline strongly empirical, that is based

on experience and past projects (“Coloro che non conoscono la storia, sono condannati a ripeterla”)

Page 26: Document1

Main problems

•  Methods to analyze and design a software product •  Architectural and design patterns •  Software development processes and their models •  Software development tools and environments •  Economic issues •  Products and process standards

Page 27: Document1

Producing software is difficult •  Complexity derives from

–  Very fast technical innovation –  Strong international competition –  Psychological issues –  Organizational issues –  Professionals not trained on sw design and

development •  Typical failures: bad project management, wrong

requirements, mediocre design •  Stakeholders with contrasting interests •  New projects start with high risks, scarcely

analyzed

Page 28: Document1

Standish Report 2003

Productivity is low

•  Analyzing 13.522 sw development projects in USA: – 66% out all projects fail (no useful result) – 82% out all projects need more time than

initially planned – 48% out all projects produce products

lacking some function required by the customers

– 55 G$ wasted in one year

Page 29: Document1

Standish : 2004 vs 2009

Page 30: Document1

The software process

Page 31: Document1

Stakeholders

Typical stakeholders in a sw process –  Designers –  Management –  Technicians –  Decisors –  Users –  Funding people –  …

Each stakeholder has a specific viewpoint on the product and its development process

Page 32: Document1

Process •  Development processes are created and

adapted to different project situations •  Both products and processes can be

evaluated for their quality •  Software needs several different layers of

development process: –  Industrial lifecycle –  Design lifecycle (reqs, build, test) –  Module lifecycle –  Operational lifecycle (eg.: portal)

Page 33: Document1

A history of software processes

Page 34: Document1

The software process •  Software process: set of roles,

activities, and artifacts necessary to create a software product

•  Possible roles: designer, developer, tester, maintenance, ecc.

•  Possible artifacts: source code, executables, specifications, comments, test suite, etc.

Page 35: Document1

Models for the software process

•  Waterfall model (planned, linear) •  Spiral model (planned, iterative) •  Agile model (unplanned, user driven)

Page 36: Document1

4+2 views SCM: sw configuration management, ALM: application lifecycle management

Page 37: Document1

Activities

•  Each organization differs in products it builds and the way it develops them; however, most development processes include: –  Specification –  Design –  Verification and validation –  Evolution

•  The development activities must be modeled to be managed and supported by automatic tools

Page 38: Document1

Mod

els:

pro

cess

dia

gram

Page 39: Document1

Lifecycle differences in the world •  Cusumano in 2003 analyzed 104 sw projects in four areas

India Japan US Europe Total Practice / No. of Projects 24 27 31 22 104 Architectural Specification 83.3% 70.4% 54.8% 72.7% 69.2% Functional Specification 95.8% 92.6% 74.2% 81.8% 85.6% Detailed Design 100.0% 85.2% 32.3% 68.2% 69.2% Code Generation 62.5% 40.7% 51.6% 54.5% 51.9% Design Review 100.0% 100.0% 77.4% 77.3% 88.5% Code Review 95.8% 74.1% 71.0% 81.8% 79.8% Subcycles 79.2% 44.4% 54.8% 86.4% 64.4% Beta Testing 66.7% 66.7% 77.4% 81.8% 73.1% Pair Testing 54.2% 44.4% 35.5% 31.8% 41.3% Pair Programming 58.3% 22.2% 35.5% 27.2% 35.3% Daily Builds

At the Start 16.7% 22.2% 35.5% 9.1% 22.1% In the Build 12.5% 25.9% 29.0% 27.3% 24.0% At the End 29.2% 37.0% 35.5% 40.9% 35.6%

Regression Testing 91.7% 96.3% 71.0% 77.3% 83.7%

Page 40: Document1

(2008)

Page 41: Document1

Productivity differences •  For the same 104 projects Cusumano got the

following data:

India Japan US Europe Total No. of Projects 24 27 31 22 104 LOC/programmer month 209 469 270 436 374 Defects/KLOC (12 mon. after delivery)

0.263 0.020 0.400 0.225 0.150

Page 42: Document1
Page 43: Document1

Software standards

Page 44: Document1

Standards

•  Many institutions define international product or process standards for the global software industry

•  Their goal is usually to improve the quality of software products and their development processes

Page 45: Document1

Software standards

•  Standard IEEE: development methods •  Standard OMG: UML and CORBA •  Standard W3C: Web technologies •  Standard OASIS: Business Process

Page 46: Document1

IEEE Standards on Software •  IEEE 828 - Standard for Glossary of Sw Eng Terminology •  IEEE 830 - Practice for Sw Reqs Specifications •  IEEE 1016 - Practice for Sw Design Descriptions •  IEEE 1012 - Sw Verification and Validation •  IEEE 1062 - Sw Acquisition •  IEEE 1063 - Sw User Documentation •  IEEE 1233 - Developing System Reqs Specifications •  IEEE 12207 - Standard for Sw Life Cycle Processes •  IEEE 1471 - Practice for Architectural Descriptions

www.computer.org/standards!

Page 47: Document1

Summary •  Software is a business, but it is not like other

businesses •  Software products are both the programs and

their documentation, included process documentation

•  A software process is a set of roles and activities to develop a software product

•  Software engineers should use effective tools and methods based on principles scientifically and ethically correct

Page 48: Document1

Questions

•  What is “software architecture”? •  What is a “service oriented architecture”? •  What are the main problems in software

architecting? •  What is an architecture-centered software

process? •  Where can I find a specific paper on a

specific software architecture topic?

Page 49: Document1

References

Textbook: Taylor & Medvidović & Dashofy, Software Architecture: Foundations, Theory, and Practice, Wiley 2009

Additional textbooks: Quian & Fu, Software Architecture and Design Illuminated, Bartlett & Jones 2009 Reekie and McAdam A Software Architecture Primer, 2006

Page 50: Document1

References

Additional textbook on software engineering: Pressman, Software Engineering, McGraw Hill, 6th ed., 2005

Additional textbook on UML: Arlow & Neustadt, UML2 and Unified Process, McGraw Hill, 2007

Page 51: Document1

Journals

(via Internet inside UniBo network): IEEE Transactions on Software Engineering ACM Trans. on Sw Engineering and Methodology IEEE Software IEEE Internet Computing (online) Journal of Object Technology www.jot.fm

scholar.google.com!

Page 52: Document1

Reference web sites

Site of the textbook: www.softwarearchitecturebook.com

IASA (int. assoc. of sw architects): www.iasahome.org

Major web sites: www.sei.cmu.edu/architecture/!www.handbookofsoftwarearchitecture.com!www.bredemeyer.com!

Blogs blog.softwarearchitecture.com!

Page 53: Document1

Questions?