T +30 6938 119424 [email protected] www.sig.eu
Startup Founder 101: IT Strategy for Startups Yiannis Kanellopoulos: SIG, Practice Leader Greece - ID-GC, Core Member Twitter: @ykanellopoulos
12/02/2014
2 I 21
Outline
• About SIG • Why software is important • Aspects of IT Strategy • Managing Your Product’s Quality
• Appendix • Examples • Supporting Material/References
3 I 21
Who we are: Spin-off of CWI and University of Amsterdam
Headquarters
…since 2010
2000 - 2005 2005 - 2010
4 I 21
We live in interesting times
“There has never been a worse time to be competing with machines, but there has never been a better time to be a
talented entrepreneur” Erik Brynjolfsson, Andrew McAfee: Race Against the Machine
5 I 21
Software is …
… the DNA of today’s
information Society
… eating the world
Prof. Dr. Ing. Joost Visser, SIG Head
of R&D
6 I 21
Software can be an expensive failure
7 I 21
… in the corporate
8 I 21
… as well as the startup world
9 I 21
The Bermuda triangle for developing your Product
Process
Methodology People
Product Developers
(internal + external)
Testing
Agile
Requirements Elicitation
Deployment
Co-founders (technical + non-technical)
Software Vendors Lean Startup
Kanban
Development
Extreme Programming
Scrum VCs
ISO 25010
Technology Selection
10 I 21
People – Forming your team: Internal development is less risky
Internal development
Appropriate when there is internal expertise on how
to build your Product
Overall control over product
Priority is given to agree upon technology and
methodology of working
Outsourcing/External
development Appropriate when there is no or limited expertise to
build your product
Moderate control over vendor
Limited control over product
Priority is given to control the deliverable of the
vendor/external developer
Offshoring (India/China)
Appropriate when the lowest cost is a priority
Almost no control over vendor and product
Priority is given to establish communication with
vendor
Moderate Risk High Risk Very High Risk
11 I 21
Methodology selection: Basic principles for developing your Product
Product has to be developed jointly between IT and non-technical people: • Non-technical provide the requirements and IT translates them into code • Both need to validate requirements and agree upon their prioritisation • Both need to test the Product, non-technical its functional suitability, IT its technical
Technical and non-technical people need to find a common language to understand each other: • Avoid jargon • Explain consequences of requirements in terms of costs (i.e. time, money) and expected
value • Learn to discuss requirements/algorithms using pseudo-code
Develop Product in increments: • Agree upon the core functionality (MVP) that needs to be implemented in first place • Improve Product in continuous increments (i.e. bi-weekly, monthly) • Form a plan with the main theme of each increment
12 I 21
Think Analytically: Pseudocode describing how to make coffee
Repetition structure
Selection structure
13 I 21
Process – Development: Each technology has its pros and cons
Technology ✔ ✖ .NET C# Enhances Productivity High productivity can also be a project risk
Objective-C Maximises user experience on iOS devices Inherits legacy C’s features that create reliability and maintainability risks
Java Safe choice A safe technology choice does not guarantee project success
PHP Easy to learn Non-suitable for large and critical web applications
Python Easy programming which allows developers to build applications that scale quickly
Complicated library landscape leads to higher development and maintenance costs
Ruby Developers tend to like it Hard-to-fix bugs and longer development time through over-use of language features
SAP Functionality ready to be used based on industry’s best practices
Custom code decreases the value of the system
Source: SIG website, www.sig.eu - News and publications: Technology Risk Reviews
14 I 21
Maintainability
Jan 2011 Apr 2011 Jul 2011 Oct 2011 Jan 2012 Apr 2012 Jul 2012 Oct 2012 Jan 20130.000.250.500.751.001.251.501.752.002.252.502.753.003.253.503.754.004.254.50
Product: Good quality builds trust
target
Target for system’s technical quality as
imposed by the Board of Directors of large
insurance company to their IT department.
15 I 21
Product: Good quality means less costs in the future
Init Build Accept Evolution
(Maintenance and Support)
Functional quality: Does the product meet the current user needs?
Software Product Quality • What is the expected lifetime of the product? • Can the product be changed easily? • What are the costs of evolving this product?
20% of *lifecycle cost 80% of *lifecycle cost
* The baseline for lifecycle cost calculations is 10-15 years
16 I 21
An analogy of a software product
Team Formation = System Design
Team Players = System
Components
Footballers = Units of the system. They are being evaluated by a
set of physical attributes
Lines of the Formation = System Components
Lines of the Formation = System Components
17 I 21
System Components: Your product should not have more than 7-9
The characteristics that a maintainable and balanced system should have, are:
• The number of components: should be between 7-9
• The relative size of components: should be of comparable size
all changes located in a single large component
most changes located in a single large component
changes can be located in one of many components
changes located in a small number of components of limited scope
18 I 21
Unit Complexity
How we define complexity • Number of decision points per unit (method/function) • McCabe, IEEE Transactions on Software Engineering, 1976
Method
McCabe: 4
Complexity Risk Profile
1-10 Clear code, small risk
11-20 Complex, medium risk
21-50 Very complex, high risk
> 50 Not understandable, untestable, very high risk
19 I 21
Unit Size
Unit size • A unit is a method, procedure or function (depending on technology) • Smaller units can more easily be reused • Smaller units have lower complexity • Smaller units can more easily be documented via their name
Size of the unit (lines of code)
Risk Profile
1-20 Easy to understand, no risk
21-50 Fairly complex, low risk
51-100 Complex, medium risk
> 100 Very complex code, high risk
20 I 21
Duplication
Duplication of code reduces maintainability • Substantial duplication implies high maintenance costs. • Substantial duplication makes bugfixing harder. • Substantial duplication makes testing harder.
0: abc 1: def 2: ghi 3: jkl 4: mno 5: pqr 6: stu 7: vwx 8: yz
34: xxxxx 35: def 36: ghi 37: jkl 38: mno 39: pqr 40: stu 41: vwx 42: xxxxxx
14 lines duplicated 7 lines redundant
21 I 21
Questions?
Yiannis Kanellopoulos [email protected]
http://www.sig.eu +30 6938 119424 @ykanellopoulos
22 I 21
Bestand
Bestellung
BudgetExterne Schnittstellen
Informationssystem
Inventur
Konzem
Logistik System Plattform
Modell
Order
Preise
Remainder
Technischer Firlefanz
Umsatz
Verkauf
Verteilung
Waren
Werbung
abt
all
alt
altware
altwarenaufnahme
anwender
best
bestand
buch
bud
bung
cg
cvlog
dba
equinox
etikett
exp
global
invk
invr
isy
jcs
kollplan
konz
liefereinheit
lsp
m
mds
mdsp
mdst
mhs
ord
ordrf
planprs
rayon
reduzierung
rep
ruestschein
ruestscheindaten
rws
statistik
sys.dba
sysjcs.jcs
sysjcs.rws
tech tradag.best
tradag.exp
tradag.isy
tradag.konz
tradag.mdsp
tradag.mdst
tradag.ord
tradag.tech
tradag.vert
tradag.xtrn
trans
translog
ums
umsatz
unt
user
verarb
vert
verteilserie
vkf
vo
warensicht
web.web
web
werb
werg
wewa
xl
xp
xpago
xplm
xsl
xtrn
3
2
65
3
49
38
4
28
3
3
453149
129123
15
4
6
89
3357
63
18
7
67
2
4 323
3
45 240179
136 103
16
1221
9
8
3
5
12
44
10
21
6
12
4
7
258
4
67
2045
6
2
5
9
34
2937
6
2
103
3
2
331
5
2
9
5
844
4
4187
51
5
9
19
10
23
4
3
4
50
8
40
2822
5
3
10
5
7
104
61
6
8
10
5
3
367
3
591868
18
6 36
5
5
2
3
10
11
46
34
2
21539
167
4362
30
3
2
13
2034
24
14710
53
5
8
3
2
22
3
4
6
51
162
8168
3
52
2
29
22
7
2
67
2
6
12
8
7
54
4 7
456
11
5
155
2
35
32
3
4
2
2
19
3
30
4
26
2
4
10
25
12
2
226133
226 13
35
2
523
5
2
55
2
14238
12
9
79
31
34
5
16
38322418
24
3
14
6
35
4
6
2
6
25
64
24
569142
9
2
3
8152
52
Example: Complex and badly architected system
23 I 21
Examples of implemented architectures
A
B
C D
E F
D
A
C
B
D
E F G
Good Example
Bad Example
24 I 21
Example: Complex Method
25 I 21
2,259 lines later
è
Example: Long Method
26 I 21
Vision of SIG
Software is the DNA of our modern information society • Invisible to most • Overwhelmingly complex • Largely determines how businesses, governments, and individuals perform
Software product measurement is key for mastering information technology • Further professionalize providers of information systems • Provide client organizations with control over quality, costs, risks • Increased transparency allows better functioning IT marketplace
Greece • SIG wants to make modest, but structural contribution to economic transformation • Through business development and joint research
27 I 21
Software Improvement Group
Why clients hire us We help organisations to be in control over their software. As we yearly analyze more than 500 software systems, we know how to advise our clients to get the best out of their IT investments.
Activity
Management advisory, fact-based Accredited software analysis lab employs analysis tools and models Experienced staff transforms analysis data into advice
Track record
Finance, government, logistics, telecom, manufacturing, energy, …
“We translate detailed technical findings about software-intensive systems into actionable information for top management”
28 I 21
Software Analysis Laboratory Key numbers
Monitoring: • 550+ systems, concurrently • 27 mln+ lines of code per week • 50+ technologies • 100+ events per week • 30+ monitor alerts per week
Benchmark: • 750+ systems • 22,000 snapshots • 160 mln+ lines of code • 100+ technologies • 3 bln+ lines of code analyzed
Software Analysis Toolkit
Pre-production database
Production database
Source code upload
Benchmark database
Satisfies sanity
checks?
File storage
Upload received
properly?
Statistical analysis
Improvements to
Significant changes?
Wait for new
Yes
No
No
Yes Yes
Yes
Monitor alert
Event Event
Analysis and feedback
No
Look at website
29 I 21
Experience stems from the corporate world
In Europe In Greece
30 I 21
Services
Software Risk Monitoring
Software Risk Assessment
• Continuous measurement, feedback, and development consultancy • Quality assurance during the entire product lifecycle
• In-depth investigation of software quality and associated business risks • Answers to specific research questions
Software Product Certification • Five levels of technical quality (maintainability) • Evaluation by SIG, certification by TÜV Informationstechnik
Portfolio Analysis and Optimisation • Combining technical analysis and application lifecycle information • Supporting portfolio evolution decisions with a sustainable roadmap
31 I 21
How to manage Software Product Quality: ISO 25010
Software Product Quality
ISO 25010
Functional Suitability
Performance Efficiency
Compatibility
Usability Reliability
Security
Maintainability
Portability
32 I 21
Elements on measuring Product’s technical quality
See: www.sig.eu/en/certification for more information.
Volume
Duplication
Unit size
Unit complexity
Unit interfacing
Module coupling
Component balance
Component independence
Analysability X X X X
Modifiability X X X
Testability X X X
Modularity X X X
Reusability X X
33 I 21
Effects of Software Product Quality (1/2) Higher quality software is built cheaper
• Higher quality software has a better design, requires less rework, can be tested more cost-
effectively, and is easier to change when requirements change • Higher quality software requires smaller teams with less overhead • (Source: SIG Benchmark data of systems built using Java or .net)