Definitions. 2014, W.Rogner RSB

Transkript

1 Definitions

2 Def: Cost free software aka Freeware Software that can be used free of charge under certain circumstances Def: Open source code Software where the source code as well as instructions and tools to build it are available Def: Public Domain Software where the creator has given up copyright or ownership Def: Free Software aka FOSS aka FLOSS Coined by the Free Software Foundation (FSF) and R.Stallman, free open source software or free and libre open source software aknowledges 4 specific freedoms: 0. freedom to run / use 1. freedom to analyze / study 2. freedom to redistribute / copy 3. freedom to improve (and redistribute) Def: Open source software Extends the definition of free open source software with appropriate licensing terms: 1. Free Redistribution 2. Source Code included 3. Derived Work allowed 4. Integrity of The Author's Source Code granted 5. No Discrimination Against Persons or Groups 6. No Discrimination Against Fields of Endeavor 7. Distribution of License without change 8. License Must Not Be Specific to a Product 9. License Must Not Restrict Other Software 10. License Must Be Technology-Neutral?: Free to run? implicit grant, currently not disputed 2013, Sources: FSF, Open Source Initiative, Wikipedia

3 Licenses

4 Open Source Licenses A license agreement is a written contract where the owner of a piece of software (or hardware) grants the licensee a limited right to use, reuse and redistribute the original work. Limitations may cover time of usage, redistribution, modifications, commercial benefits and others. Open Source license to some extent embed the concepts of freedom. They prevent open source software from inadvertent commercial take-over, protect intellectual properties and protect from inappropriate patent claims. Copyleft Permissive Copyleft licenses enforce derived products to inherit their parents licenses. Weaker versions allow a change of license for derived work. Later limitation of rights to use and modify the software are precluded. Permissive licenses allow the software to be operated in proprietary, closed source environments and still support the concept of freedom. e.g. GPL, Apache, Components under copyleft licenses are viral in respect to being embedded in larger systems. The embedding system must comply to the copyleft license of the embedded component. Permissive licenses do not ban restrictions explicitly as opposed to copyleft licenses. e.g. BSD, MIT,... Choices Copyleft: Right of ownership moves down to derived work Work plus derivatives stay free forever Utilisation limited to non-commercial implementations best for in-house development Permissive: Right of ownership stays with the originator Derived work might be commercialised by third party Unlimited distribution (commercial and noncommercial) best for development in competitive environments

5 Source:

6 Source:

7 Cost development

8 Budget development as desired by IT Granted IT Budget Cost development imposed by commercial vendors Projects and innovation Not operation critical Omitable in short terms IT-Budget as granted by business management Operational expenses Externally inflicted by vendors Not customer adjustable Increasing in long terms Slack for Innovation vanishes t Reduction of license payments leads to lower operational costs thus increasing the margin for new projects

9 Maintenance fees go to the vendor Extended maintenance fees add to the vendors cash flow. Product maintenance is stopped (EOL) License costs of proprietary systems are due for new systems and upgrades approx. same as license costs... License Maintenance... extended Maintenance t expected service life Replacement without extended business value infeasible License fees go to the local subsidiary forcing them to sell additional products Economical Lock-In This is part of a TCO calculation Cost for hardware and personnel are invariants and thus ommited

10 Subscription fees support product enhancements Termination and re-entry of subscription is possible any time Savings partly used for migration License costs of open systems are significantly lower than proprietary fees. They go directly to the vendor Scaled down sales and distribution channels lead to reduced license fees... License Maintenance... Community editions used t maintained service life extended service life TCO calculation needs to extend general 5 year period to unveil strategic benefits Savings increase budget for innovations Cost for hardware and personnel are invariants and thus ommited

11 Misconceptions

12 Source: Analysis of arguments against Open Source and Open Solutions: Separating truth from myth, W.Rogner (2012)

13 Missing Support Missing liability and warranty Missing skilled personnel Longterm sustained availability Increased risk Insufficient functionality Missing user acceptance Incompatible to PS and legacy Legal issues Hidden costs Missing documentation Insufficient usability Higher implementation effort Lack of applications / fragmentation Inferior quality Untested Unreliable systems Missing commercial model Small installed base & network effects Higher maintenance effort Lack of innovation Unprofessional creation process Inconsistent design Vendor/Developer Lockin Low performance Lack of political influence Requires new approach from IT 0 0,02 0,04 0,06 0,08 0,1 0,12 Source: Analysis of arguments against Open Source and Open Solutions: Separating truth from myth, W.Rogner (2012)

14 Medical care Social Marketing e-commerce Planning, Design Project Management Applications Process Management Claim: There are not enough applications based on open source CAD, CAM Enterprise Content Management Customer relation & Supply chain Enterprise resource planning Financial services Access & Security Task automation Presumption: If one can find one or two applications in each category of the stack, one can assume there are sufficiently enough solutions in to cover the demand wth open source software. Constraint: References must cover standard professional requirements in an enterprise environment. A complete coverage is neither required nor achieved by proprietary counterparts. Office & Documents Search Engines Information Knowledge Management Document Management Business Intelligence BP & Workflow Data Management Communi Cation Video conferencing Collaboration & Groupware Instant Messaging VoIP & Telephony Archive Mail Printing Scanning Archiving Client Presentation Persistence OS Client virtualisation Enterprise Architecture Mgmt Manage ment Service Management System Management Security Management Inventory Deployment Client customisation Application platform Data Warehouse Directory services Enterprise service bus Server Message queues Database RDBMS Database NoSQL Database Frameworks Small business server OS Cloud Virtualisation Storage Framework Develop ment Question: Reporting & Visualisation Build Version management Language Tools 2014, W.Rogner Does Open Source cover sufficiently each category of the application stack?

15 Medical care Applications Social Marketing User Voice e-commerce Magento OSCommerce Planning, Design OpenProj Planner TaskJuggler ArgoUML Dia Umbrello Magic Draw Umlet PLMworx Project Management Hamster Fanurio Kimai ChilliProject Tine OpenProj project-open openitsm trac Process Management ProcessMaker Bonita Studio CAD, CAM Enterprise Content Management Information Communi Cation Archive Nuxeo EP Alfresco dotcms exo WCM ez Publish Helium V Liferay Portal Concrete 5 Pivot X papayacms MTOS Openbravo OpenCMS OpenKM Plone Zope WordPress CMS md. simple Redaxo Silverstripe Newscoop OpenEMM Axiis NextReports MediaWiki Davical Blue Mind Kerio conversations Zentyal OpenDaylight Concourse suite OneOrZero Dolibarr trac Compiere ERP5 WebERP Dolibarr AvERP Tryton HeliumV Nuclos ERP xtuple Postbooks OpenZ CaniasERP opentaps Skrooge GnuCash Kraft Verinice SourceID OpenAM/IDM FengOffice Scribus PageStream VivaDesigner OXDocuments exist exo KM Limesurvey Moodle OLAT Protégé ILIAS RawTherapee Rawstudio Darktable OpenSplice DDS LibreOffice Search Engines OpenSearch Srv. eccenca Knowledge Management Knowledge Tree OpenOLAT Document Management agorum core Alfresco Reporting & Visualisation ireport JasperReport JasperOLAP Tempo ImageMagick UFRaw Business Intelligence Pentaho SpagoBI BIRT JasperSoft Knime OpenI Intalio BPMS jbpm openitsm JBoss BRMS Tempo Sopera OpenXchange Kolab Zimbra Flow3 Algernon-J exo Plattform CloverETL Sopera Talend OpenSt. Placecam Open Meetings Jabber Skype Airtime Egroupware Horde Simple Grpw. UCS FengOffice Zarafa OpenFire Jabber OpenMeetings Pidgin Empathy Instantbird VoIP & Telephony Asterisk HylaFAX sipxecs Trixbox Airtime Gemeinschaft Mail Dovecot Postfix Mailman mlmmj SpamAssassin conversations Printing Scanning CUPS Bacula Amanda Presentation Gnome KDE HTML Persistence Hibernate SuSE Ubuntu Gentoo Client virtualisation Papageno VueScan Archiving OS Ametys Joomla Compiere Instant Messaging animble Drupal ADiempere Collaboration & Groupware icescrum Magnolia ADiempere Video conferencing OpenProjectile Typo 3 vtiger CRM Data Management OnePoint Magento Apache OFBiz BP & Workflow aceproject Ares Commander OpenERP Office & Documents Client exo Social SugarCRM Task automation Manage ment OSQA Enterprise resource planning Access & Security RedHat Zmanda Open Benno Mailarchiv Mailarchiva Android Enkive Piler Heinlein Elements Mail-Archiv Openarchive SEP Sesam Fedora Spice Enterprise Architecture Mgmt iteraplan EPF Essential MappIT Archi I-doit Service Management OpsView Opsi OTRS i-doit openitcockpit openitsm System Management Landscape OpenNMS VNC Nagios Shinken Proxmox VE Incinga Groundwork Mon Hyperic HQ opennms Terracotta ZABBIX Security Management Suricata IDS IPFire OpenVAS OpenVPN OpenSwan StrongSwan ClamAV Jasig CAS Shorewall Smoothwall Expr. Wireshark OSSEC ACMP Pro Ovirt OCS-Inventory Puppet Mcollective Chef JuJu Uranos M23 Spacewalk Pulp Fog OpenVenus Client customisation UCK Remastersys Customizer Relinux Application platform Apache Node.js Nginx JBoss Tomcat AppScale Typhoon AE Monkey Zato PEtALS Zato Sopera OpenLDAP InfoGrid Neo4j Objectivity Infinispan exist Stratus Lab Inventory Deployment Data Warehouse Hive Directory services OpenLDAP Sesame Mule Servicemix Talent ServiceMix Synapse OpenESB ActiveMQ FUSE HornetQ Sandesha2 RabbitMQ OpenMP Database RDBMS PostgreSQL MySQL MariaDB SQLite DB2 Database NoSQL Hadoop Redis MongoDB CouchDB TokyoCabinet Database Frameworks Drizzle Hibernate Small business server Amahi ClearOS OS RedHat SuSE Ubuntu Gentoo OpenBSD NetBSD CentOS OpenStack OwnCloud Sparkleshare Eucalyptus OpenQRM OpenNebula CloudFoundry Nimbus Cloud-init Seattle VMWare KVM VirtualBox WINE UCSDVS Nomachines NX OpenNebula XEN Spice QEmu Django Spring Zend Trac Bugzilla Modelio OSRTM animble Enterprise service bus Message queues Server Zoho Support Customer relation & Supply chain Financial services Cloud Virtualisation Develop ment Tempo Get Satisfact. Storage Samba Framework GTK+ Qt JQuery Open QA Dojo Ant Maven Jenkins Hudson JavaScript Build Version management Language 2014, W.Rogner Tools Git Bazaar Mercurial Subversion Cruise Control C/C++ Java Python Perl JavaScript Eclipse GForge Meastro Netbeans Sonar MemcacheDB rmtoo OpenQM

16 SWOT Analysis

17 Strength Freedom to use Free access to software and source code independence from single vendors platforms independence free upgrade at users own pace Evolution of software many voluntary developers quick bug fixes code reuse Time, cost and effort lower development costs quicker bug fixes no license fees flexible maintenance fees code reuse no time and budget restrictions during development Quality of software reduced number of bugs user feedback constant peer review intrinsic code quality (out of programmers self esteem) vulnerabilities found quicker alternative code distribution channels Advantages to companies and programmers efficient use of knowledge learning by example gaining programming experience opportunities to collaborate rapid development Compatibility Suitable for certain (not further specified) types of projects Availability Easy access to OSS Economical demand driven maintenance fees reduced effort to handle license agreements beneficial to the local economy long term savings license model allow flexible development low TCO Community community carries some development cost Weaknesses Management planning and delivering OS community projects is challenging coordination and collaboration difficult complex resource allocation and budgeting fluidity of developers (varying interest) existing cost and business models are inadequate generating revenue is demanding good programmers are hired by PS companies Quality and security lack of quality documentation applications not always intuitive no generally accepted style guides competition for qualified programmers open source invites cyber terrorists fewer applications per problem domain available Lack of usability Legal issues legal uncertainties and risk through software patents warranties and guarantees Compatibility limited network effects (no broad installed base) limited support for proprietary document standards Adoption difficult migration path slow adoption by companies Economical OSS model open to free rider syndrome

18 Opportunities Business opportunities Strategic value of OSS indicated Adoption by large IT vendors (IBM, HP, Oracle,...) Proven business models available OSS acknowledged as business alternative Adoption Large scale adoption in 3rd world and developing countries OSS being complementary to sold products Wide adoption by hardware and embedded system vendors OSS methods adopted in different industrial areas (open innovation) Awareness Publicity and awareness Threats Legal issues Changing legal regulations Patent laws in EU Patent vaults Monopolised markets Community disintegration Outdated, unchallenging projects Eliminated personal benefit Members outgrow group Technology Heterogeneous software pool License issues Specific application domains not covered by OSS Economical Migration projects infeasible Reference migrations unsuccessful

19 Freedom of use Evolution of software Time, cost and effort Quality S Advantages to programmers and companies Compatibility Availability Economical Community Management Quality and security Legal issues W Compatibility Adoption Economical + + Economical Community Legal issues Awareness -?? ++ ++?? u u? --? o?? u u? u A B -- C D E? - u F G promoting impact demoting impact open issue neutral outcome unresolved issue (missing project management) Creator Combiner Capitaliser demoting impact open issue neutral outcome unresolved issue (missing project management) RO R RO RO RO RO R A RO OA R ROA A RO A RO A ROA R? u A?? u u B ROA C D E Economical Technology Community Legal issues T Awareness O Business opportunities Freedom of use Evolution of software Time, cost and effort Quality S Advantages to programmers and companies Compatibility Availability Economical Community Management Quality and security Legal issues W Compatibility Adoption Economical A1 B2 A3 B4 A5, B5 C6, C7 A8, B8 C ROA 5 6 A ? u F G Strong flexible position (business model, technology) exponential growth of users, contributors and fields of application Exposure of strategic benefits (VI, SC, Iop) -> new products Raising quality -> wider adoption -> Sen will take effect 3rd world, Asia will offer new applications, Problem: asiatic languages wider adoption, marketing required lower cost -> wider adoption in use and as sub-product -> increased revenue Community will demand gratification of development efforts A10 Without management no business, controlling needs improvement B11 Development of style guides and common UI required A12, B12 Legal clarification on OSS adoption required, clear communication, patent pools (for trading), lobbying agains SW patents D1, D3, D8Code reuse might trigger law suits, as OSS is open (see Dalvik), constant threat, IP, increases TCO calculation F1 accept and utilise, technological wealth is positive F2, E5, E7, Uninteresting E9 areas of software development needs corporate funding, Introduction of compensation mechanisms (Google summer of code) G6 consolidation before migration F11 D12 F12 F13, F14 TOWS Matrix R O A? o u T ++ Adoption +? o u Adoption Business opportunities O Technology TOWS Matrix Style guides, development standards Establish a group of legal and license experts Contract management see F2, E5, E7, E9

20 Development cycle definition

21 Open Source development model (A.Christl, 2007) Source:

22 OSS in U.S. Government Acquisitions (D.A.Wheeler, 2010) Fix bugs Integrate features (upstreaming) Developer Report bugs Add features Trusted Developer Trusted Repository Flo wo Report bugs Distributer fs ou r ce cod e User Source:

23 Open Incremental Model (Mandal, Kandar, Ray 2011) Source: Open Incremental Model - A OSS Development Life Cycle Model (OSDLC) - Mandal, Kandar, Ray (2011)

24 Open source software development (Wikipedia 2014) Source:

25 Users work with the software as is They add critical mass anonymous tester patcher committer core coder packager early adopter Testers and early adopters find and report errors in the software They add quality Patcher and packagers adjust the code to different environments They add portability *) Committers add new functions and correct errors They add functionality Core coders assemble all contributed code in releases They lead development user Depending on the size and maturity of the software project, boundaries might be more or less strict *) As the software project matures, users might start testing, patching, contributing code fixes and even aspire to become core coders Core coders might move on to new projects

26 Relation between input resources, quality and usability

27 In the long term open systems will have better quality than proprietary close source software Q Qo Quality Q directly relates to the resources r (=developers) put into a project (c closed source) Qc Q= r ro t rc t Qc Quality of closed source software (green) rc resources in closed source software project (green) Qo Quality of open source software (blue) ro resources in open source software project (blue) Resources allocated to open source projects will eventually outnumber any commercial project Resources allocated to closed source projects will eventually be substituted by marketing efforts

28 The utility U of any software is a function of quality, functionality, performance, stability and usability (user friendlyness) Increased usability (+0,4) of OSS mainly due to increased quality. U =f (Q, F, P, S, uf ) U U 1,1 1,0 1,0 Added value of CSS secures its market position 0,7 Added value through service and support of OSS 0,6 Added value through service and support of OSS 0,2 OSS OSS-SS CSS OSS open source software OSS-SS open source software with service and support CSS proprietary, closed source software The utility of closed source software is set initially to 1 as a reference, that of open source 0,2 and support adds value of 0,5 Value gap of CSS CSS out of market OSS OSS-SS CSS OSS open source software OSS-SS open source software with service and support CSS proprietary, closed source software The utility of open source software with service and support outperforms closed source software by a margin. This drives CSS out of the market

29 Comparison of different development approaches

30 Traditional (Waterfall, V-Model) Requirements definition Software specification functional specification IEEE Design Design specifications SDD Estimation of efforts Work packages cost estimation project plan Sequential milestones implementation phases Test management (unit, load, integration, ) quality management SPMP development test and production stages Service and operations usually unaccounted for SCMP Implementation Tests and QM Deployment SQAP Software Quality Assurance Plan IEEE 730 SCMP Software Configuration Management Plan IEEE 828 STD Software Test Documentation IEEE 829 SRS Software requirements specification IEEE 830 SVVP Software Validation & Verification Plan IEEE 1012 SDD Software Design Description IEEE 1016 SPMP Software Project Management Plan IEEE 1058 SUD Software User Documentation IEEE 1063 SRS Agile (SCRUM, XP) Product idea vision back logs User stories Sprints Story points Estimation meetings small implementation units sprints Incremental implementation SQAP, 2-stage handover: STD, - Product Owner and SVVP - end user retrospective meetings SUD Open development Roadmaps bug tracking feature lists Ad-hoc evolutionary approach Rudimentary planning release early release often Unsynchronised Peer and community reviews feedback bug tracking feature requests not part of the methodology, Incremental releases depends on organisation continuous integration not part of the methodology Community driven Open development offers light weight project- and effort management and a simple tool set

31 Who can use OSS? OSS utilisation with resp. to type of adopter large medium small Creator (SW-developer) Combiner (value added vendors) Capitaliser (users)?

32 Business model theory

33 J.Koenig (2004) Source: Seven Open Source Business Strategies, J.Koenig (2004)

34 Z.Ehrlich & R.Aviv (2007) Support Sellers Give away software for free, charge for service and support Examples: Red Hat, Oracle, Canonical Loss leaders Develop free basic software, sell value added applications on top Examples: IBM / Eclipse Widget froster Enhance hardware / software with free open source components Examples: Samsung, Synology Accessorisor Sell complementary or extending software, hardware or material Examples: books, mugs, t-shirts, Raspberry Pi Source: Handbook of Research on Open Source Software, Chapter XV, K.St.Amant, B.Still (2007)

35 Cost model comparison B.von Rotz (2007) Source: Cost model comparison: PS vs. OSS, von Rotz B. (2007)

36 Cost model comparison Semper (2009) Source: Cost model comparison: PS vs. OSS, von Rotz B. (2007)

37 Strategic adjustment factors

38 Strategische Unternehmensführung Gälweiler (1990) Aufgabenbereiche Orientierungsgrundlagen Steuergrößen Zeithorizont strategische Führung Substitutionszeitkurve Komplexität neue technische Lösung Kundenproblem Neue Erfolgspotentiale Erfahrungskurve Marktposition Bestehende Erfolgspotentiale Bilanz Aufwand + Ertrag Erfolg Einnahmen + Ausgaben Liquidität operative Führung kurzfristig langfristig

39 Strategisches IT Management v3.0 Tiemeyer (2010) Aufgabenbereiche Orientierungsgrundlagen Steuergrößen Zeithorizont strategisches IT Management Substitutionszeitkurve Komplexität neue Technologien Qualität, Effektivität, Effizienz Flexibilität neue Geschäftsfelder Ziele, Nachhaltigkeit Effektivität Geschäftsprozesse Kosten + Gewinn Effizienz Kundenanforderungen Anforderungen + (techn.) Aufwand Qualität operatives IT Management kurzfristig langfristig

40 Open Source im strategischen Orientierungsrahmen Aufgabenbereiche Orientierungsgrundlagen Steuergrößen Zeithorizont strategischer Nutzen Substitutionszeitkurve Komplexität neue technologische Einsatzgebiete Verbreitung, Akzeptanz, Ecosysteme Netzwerkeffekte Reuse, Ecosysteme Open x Entwicklung Herstellerneutral einf. Deployment Communities Unabhängigkeit Leichtgewichtig, globale Prozesse Qualität, Transparenz, Commoditisierung Verfügbarkeit Akzeptanz Lehrinstrument Auswahl, Einführungskosten, Umsetzungsdauer Servicefähigkeit operativer Nutzen neue Technologien = Wissensvorsprung persönlichindividueller Nutzen Kompetenz Expertise USP Akzeptanz unter Peers Visibilität pers. Zufriedenheit wirtschaftl. Erfolg kurzfristig langfristig

41 Open Source Strategic map Value (chain) lexikalisch-semantische Methoden Content Analytics Big Data Analytics (focusing on development of Big Data Analytics) statistisch-mathematische Methoden? automatische Modellbildung?? Open Data Open Innovation CMS Open Source Big Data BI Open Content (Google, Wikipedia) Proprietary Formats, Industry Standards Genesis Custom built Open Formats Norms, Standards Product (+rental) Open Standards Commodity (+utility) Evolution

42 Complexity margin denotes the maximum complexity achievable with a certain technology stack. The effort to meet this complexity becomes infinit Effort Effort to achieve results increases to an economical maximum ( ). This maximum depends on the underlying technology Languages Asm C Basic Algol... 4GL, OO CASE IDE... Tools Frameworks Methods JDK, J2EE.NET Rails, Django... Complexity Modularisation, SPL CI DevOps...

43 Probability of finalization (T.DeMarco 2003) Prel (%) Wicked problems (H.Rittel, 1970) Problem Most likely finalisation date Gather data Analyze data 50% risk to miss deadline P t =1 Impossible to finish earlier Formulate solution t =0 Implement solution Solution Duration of critical path t 70% risk to miss t Development dilemma Degree of finalisation 100% Developer self-assessment Why projects are late by design (E.Risch / W.Rogner, 2013) Degree of implementation Observable progress Required scope after implementation 100% Committed scope Delivery gap at end date Procrastination Underestimation of project complexity Gold t plating Utility of innovations during change Closing point determined by metrics Project delay (overlayed with 7 phases of change management) Utility Announced End date Project signoff t (projected) revised by Post project phase end date management Freeze Thaw Transform Harvesting benefits t

44 Initiative Idea Development Resources Funding Governing (protecting) Information Business Model Revenue

45 Requirement engineering

46 Mitte April treffen sich ein paar Engagierte um sich sportlich zu betätigen Am findet der Wien Marathon statt Gestartet wird bei der UNO-City Zuerst wird ein wenig durch Wien gelaufen Um 8:57 starten die ersten Läufer Die Strecke: Wagramerstraße - Reichsbrücke - Lassallestraße Praterstern - Hauptallee - Stadionallee - Schüttelstraße Untere Donaustraße - Schwedenbrücke - Franz Josefs Kai Stubenring - Parkring - Schubertring - Kärtnerring Opernring - Operngasse - Friedrichstr. - Linke Wienzeile Schloßallee - äußere Mariahilferstraße - innere Mariahilferstraße - Babenbergerstr. - Burgring - Dr. Karl Renner Ring - Universitätsring - Schottenring Liechtensteinstraße - Alserbachstraße - Julius Tandler Platz Friedensbrücke - Brigittenauer Lände - Obere Donaustraße Untere Donaustraße - Schüttelstraße - Lukschgasse Rustenschacherallee - Stadionallee - Meiereistraße - Stadion (Wende) - Meiereistraße - Hauptallee - Lusthaus - Hauptallee - Stadionallee - Schüttelstraße - Franzensbrücke Radetzkyplatz - Radetzkystraße - Vordere Zollamtstraße Weiskirchnerstraße - Stubenring - Parkring - Schubertring Kärntner Ring - Opernring - Burgring - Heldenplatz Dann geduscht Ziel: Heldenplatz bis 15:00 geöffnet Dann ein wenig gefeiert Siegerehrung der Top 3 direkt nach dem Zieleinlauf

47

48

49 Definition Anforderungsmanagement (Requirements Management) Prozess um die Anforderungen an Softwaresysteme zu erheben, dokumentieren und warten (Kotonya G. and Sommerville, I. (1998) Requirements Engineering: Processes and Techniques. Chichester, UK: John Wiley & Sons) Erheben Identifizieren (bewerten, priorisieren, gewichten) Analysieren (Widersprüche entfernen) Spezifizieren (niederschreiben) Modellieren (Realität abbilden) Validieren und verifizieren (Widerspruchsfreiheit garantieren) Laufend anpassen (Veränderungen zulassen)

50 Definition Anforderung Eine Anforderung ist eine Aussage über eine Eigenschaft oder Leistung eines Produktes, eines Prozesses oder der am Prozess beteiligten Personen. (Rupp, et.al, 2007)

51 3 Hypothesen H1: Requirements Engineering ist redundanter Overhead H2: Tools: Es reicht Word (ev. Excel) H3: Open Source Projekte sind effektiver (bei der Anforderungsspezifikation)

52

53 IT behindert Geschäft Externe DL ist Experte Auftrag an DL GF Gericht (SV)? Ziel / Auftrag? Mittel geeignet? Umsetzung sachgerecht Anforderungsdokumente Eskalation Braucht schnelle Lösung Kann kein UML Kunde IT Will formale Anforderungen (UML?) Abnahmekriterien Planungsbehelf: Kosten, Aufwand Zeit, Skills, Tools Interne Constr aints der IT u nb Geht zum Kunden / vor Ort kurze Vorerhebung, Angebot + Risikoaufschlag ekannt / egal DL Braucht kein UML Versteht den Kunden Umsetzung verzögert sich

54

55 Methoden: ORDER Disziplinen, Werkzeuge: Geschäftsprozessanalyse, Modellierung, UML, Use Cases, Workshops, Riskmgmt., Projektplanung (PSP, PAP), Aufwandsschätzung, Gesprächstechniken, Vertragsgestaltung, Verhandlungen, Projektkostenrechnung, Ressourcenplanung. CRM, ER, Bubble-Diagramme, FPA, etc. Vorprojektphase Methoden: Wasserfall, V-Model, Spiral, MSF, RUP, SCRUM, XP, System Engineering, Kaizen, ShopFloor, LO, PMI, PMA, Betrieb: ITIL, Weiterentwicklung, Wartung, Help Desk, Versionen, Schulung Disziplinen, Werkzeuge: Geschäftsprozessanalyse, Modellierung, Workshops, Riskmgmt., Projektcontrolling, Teamtechniken, Ressourcenmgmt. CRM, Projektmarketing, Krisenmgmt., QM, Configuration Mgmt., Programmierung, Style Guides, Prozessmgmt., Vertragsgestaltung, Wartung, Change Mgmt., etc. Ausserdienststellung: Datenübernahme, Datenentsorgung, Schnittstellenanpassung, Recycling, Reengineering, Refactoring Projektstart Anforderungsmanagement AM Projektende t

56 ORDER: Best practice Projektmanagementmethode für die Vorprojektphase nach Mahan Khalsa (Let's get real or let's not play, 2008) O (pportunity) Kein Bedarf, kein Problem Kein Projekt R (esources) Unzureichende Kapazitäten für Projektdefinition Kein Projekt D (ecisions) Keine Entscheidungen in der Vorprojektphase Kein Projekt E (xact solution) Konzentration auf eine Lösung Keine Entscheidung Kein Projekt R (elationship) Produktive Beziehung aufrecht halten 1) Auftrag wird erteilt 2) Auftrag wird nicht erteilt 3) Es fällt keine Entscheidung Professionelle Umsetzung Wenn O,R,D professionell waren, ev. Folgeauftrag Kein Projekt

57 Wissen über das Zielsystem 2011, agile-dojo.de

58 Wasserfall Prototyping Inkrementell Evolutionär V-Model Spiral 1999,

59

60 Inkrementell V-Model Roadmap Wasserfall Reality Gap Mogelpackung Reality Gap Prototyping Spiral User Interaktion Evolutionär Designmängel Mangelnder Überblick rs Ve io r te nie Ro m ad ap 1999,

61

62 Standard-SW Individual-SW wenig Funktionsvergleich umfassend funktional nichtfunktional kommerziell Unkritisch Kritisch informell Text Tabellen UML BPML ER Pretri-Netze Zustandsdiagramme Graphen formal Logiken Algebren Kurzlebig Langlebig rudimentär Funktionen Schnittstellen detailliert Abläufe IT-Betrieb (DevOps) Wartung und Entwicklung

63 Individual-SW niedrig - Dokumentationsgrad - hoch Logiken Standard-SW Aussagen-L Prädikaten-L Graphen UML ER Calc Text ku rz ns e b Le r e u da Petrinetz Domainsprachen Zustandsdiagramm g lan BPML informell formal prüfbar unkritisch Algebren - Kritikalität der Anwendung - kritisch

64 Lastenheft (Fachkonzept) Pflichtenheft (Lösungskonzept) H.Balzert Anforderungslisten DIN (PM) Zustandsdiagramm (Stoppuhr) Petri-Netz Entscheidungsbaum Zustände := { Bereit, Zeitmessung läuft, Zeit angehalten } Aktionen := { Start/Stop, Zwischenzeit, Reset } Schwerpunkt liegt auf f(x) Anzeige := { h, m, s h [0..23] m [0..59] s [0..59] } t = 0:00:00 ( h:mm:ss (Stop (Läuft Zwischenzeit) ) z1 = Bereit, z2 = ZM läuft, z3 = ZM angehalten z = t ( z1 z2 z2 z3 z3 z1) Verschiedene Logiken

65 Traditional (Waterfall, V-Model) Requirements definition Software specification functional specification IEEE Design Design specifications SDD Estimation of efforts Work packages cost estimation project plan Sequential milestones implementation phases Test management (unit, load, integration, ) quality management SPMP development test and production stages Service and operations usually unaccounted for SCMP Implementation Tests and QM Deployment SQAP Software Quality Assurance Plan IEEE 730 SCMP Software Configuration Management Plan IEEE 828 STD Software Test Documentation IEEE 829 SRS Software requirements specification IEEE 830 SVVP Software Validation & Verification Plan IEEE 1012 SDD Software Design Description IEEE 1016 SPMP Software Project Management Plan IEEE 1058 SUD Software User Documentation IEEE 1063 SRS Agile (SCRUM, XP) Product idea vision back logs User stories Sprints Story points Estimation meetings small implementation units sprints Incremental implementation SQAP, 2-stage handover: STD, - Product Owner and SVVP - end user retrospective meetings SUD Open development Roadmaps bug tracking feature lists Ad-hoc evolutionary approach Rudimentary planning release early release often Unsynchronised Peer and community reviews feedback bug tracking feature requests not part of the methodology, Incremental releases depends on organisation continuous integration not part of the methodology Community driven Open development offers light weight project- and effort management and a simple tool set

66 MUSS 90% Statisch höchste Qualität SOLL 30% Dynamisch Evolutionäre (konkurierende) Entwicklung kann 20% Unbekannt Plug-Ins 140% + Release early, release often + kleinen Entwicklungsschritten + Featurelisten + langfristiger Planung (Roadmap)

67

68

69

70

71

72

73

74

75

76

77

78 H1 H2 H3 Redundanter Overhead Word ausreichend Open Source effektiver Planungsinstrument Kontrollinstrument Baseline Keine formale Prüfbarkeit Unzulässig simplifizierend Fehlende Versionierung Keine Modellierung + Direkter Kundenkontakt Rasche Versionsfolge Einfache Tools Roadmap Alternative Bewertungen - Keine treibende Kraft Erfordert Spezial-Skills

79 Anforderungsmanagement konzentriert sich auf die (Spezifikation der) Lösung aber nicht auf die Ursachen und (zugrundeliegenden) Probleme.

80

81

82 Frequently given (unsolicited) answers Open Source ist nicht ausgereift Es gibt eine Vielzahl von Open Source Projekten. Einige werden seit Jahrzehnten betrieben, einige sind sehr jung. Manche Projekte werden von wenigen Enthusiasten, andere von Universitätsverbunden in Zusammenarbeit mit der Industrie entwickelt. Wesentlich ist, dass auch unausgereifte Software im Lauf der Zeit (mithilfe einer aktiven Community) reift. Stirbt ein Projekt mangels Unterstützung, dann bleibt der Source Code und damit die Erfahrungen allerdings erhalten und gehen in andere (Nachfolge-) Projekte auf. Beim Ausbau neuer Geschäftsmodelle werden Unternehmen möglicherweise keine ausgereifte Automationsunterstützung vorfinden. So standen Amazon, Google und Facebook vor Herausforderungen im verteilten Datenumfeld, welche nur durch Einsatz von Open Source Lösungen überhaupt beherrschbar wurden.

83 Frequently given (unsolicited) answers Open Source wird nicht unterstützt (im Sinne von: Es gibt keinen professionellen Wenig überraschend ist die Bereitstellung von Service und Support eines der Support) funktionierenden Geschäftsmodelle im Open Source Umfeld Ungeachtet der Unternehmensgröße bieten sich hier eine Vielzahl von Geschäftsmodellen an, welche erfolgreich etabliert sind. So können sich kleine Unternehmen auf ein Produkt spezialisieren und nachhaltig prosperieren und wachsen (siehe Heinlein in Deutschland). Die Hersteller großer Distributionen bieten professionellen Support sowohl bei zentraler IT als auch dem dezentralen Client (siehe RedHat, SuSE und Canonical). Neben umfassenden Lösungskatalogen gibt es auch Verzeichnisse von Anbietern von Service und Support. Einige Versicherungen bieten bereits Pakete speziell für Open Source Lösungen an.

84 Frequently given (unsolicited) answers Open Source Support ist teurer als die Lizenzkosten proprietärer Hersteller Diese Aussage konnte im direkten Preisvergleich namhafter Produkte und Hersteller nicht nachvollzogen werden. Es kann vereinzelt Anbieter von Supportdienstleistungen geben, die überzogene Preise verlangen. Das Schöne daran: Man muss nicht kaufen. Was nichts kostet kann nichts wert sein Ein Großteil der Open Source Lösungen sind Embedded Systeme. Diese werden als intelligente Steuereinheiten in Gesamtsysteme verbaut. In einigen Fällen kann es von strategischer Bedeutung sein, auf Open Source zu setzen (Wartung, Weiterentwicklung, Sicherheit, etc.). Von der Unentgeltlichkeit von Komponenten auf den Nutzwert rückzuschließen ist nicht sinnvoll. Es kann für Unternehmen sinnvoll sein, eigene Entwicklungen als Open Source zu veröffentlichen, insbesondere wenn keine Kernkompetenzen betroffen sind.

85 Frequently given (unsolicited) answers Linux am Desktop funktioniert nicht Linux funktioniert sowohl am Desktop als auch im Serverbereich. Es gibt eine Vielzahl ausgereifter Rolloutverfahren und mechanismen am Markt, sowohl Open Source als auch kommerziell. Mit Ausnahme exotischer Desktop-Anwendungen gibt es für fast jede Anforderung eine Open Source Lösung Unsere User haben sich an Windows und Office gewöhnt Der Kern von MS Windows und MS Office sind seit über 10 Jahren unverändert (mit Ausnahme absolut notwendiger Anpassungen). Geändert hat sich die Oberfläche und die erzeugten Datei-formate. Diese ändern sich im 3 4 Jahres-rhythmus um Anwender zum Hochrüsten zu zwingen. Ein Umstieg auf Linux und dort verfügbare Officelösungen ist aus Usersicht nicht komplexer als die Einarbeitung in eine neue Version von Windows (2000, XP, Vista, 7 und 8) oder Office (XP, 2000, 2003, 2007, 2012 und 2014). Open Source Dateiformate sind über Jahrzehnte stabil (siehe ODF)

86 Frequently given (unsolicited) answers Wir haben sehr gute Preise Bei Ablöseinvestitionen sind neben den einmaligen Herstellungskosten auch die laufenden Bereit-stellungs- und Betriebskosten zu berücksichtigen. Bei mehreren direkten Preisvergleichen konnte ein Preisvorteil der proprietären Lösungen nur in speziellen Szenarien nachgewiesen werden. Hier sollte ein Readiness Check Klärung verschaffen. Wir haben die Lizenzen bereits im Haus Entgegen den Behauptungen der proprietären Hersteller gilt auch für Software der Erschöpfungsgrundsatz (zumindest in Europa). Gebrauchte Lizenzen können, analog zu gebrauchten LKWs wieder veräußert werden. Diese Verkaufserlöse sollten in eine RoI-Betrachtung auch eingehen.

87 Frequently given (unsolicited) answers Open Source ist eine Randerscheinung Tatsächlich kann man den Eindruck bekommen, wenn man in Österreich oder auch Deutschland arbeitet. Anders sieht die Situation in Zentral- und Osteuropa aus. Dort ist Open Source ein fester Bestandteil der IT-Industrie. In Südamerika haben sich die Staaten geeinigt, proprietäre Software weitgehend durch offene Lösungen zu substituieren. Sie sind damit ziemlich erfolgreich. In Asien, speziell China, finden offene Lösungen laufenden Zustrom. Seit China der WTO beigetreten ist, kann es Raubkopien nicht offen unterstützen. Open Source ist eine Alternative. Indien nutzt sowohl proprietäre als auch offenen Systeme. Die hohen Kosten geschlossener Software zwingen zur Nutzung von Open Source. Die Liste ist beliebig verlängerbar.

88 Frequently given (unsolicited) answers Open Source ist von Nerds für Nerds Open Source wird unter anderem zu Bildungs-zwecken in Universitäten eingesetzt. Dass Lösungen in Spin-offs auch produktiv eingesetzt werden ist damit ziemlich wahrscheinlich. Auch ist nicht zu leugnen, dass ein beträchtlicher Teil von Open Source Lösungen von jungen, unerfahrenen Leuten programmiert wird. Das hat gerade in jüngster Zeit vereinzelt zu Beeinträchtigungen der Stabilität, Verfügbarkeit und Belastbarkeit von Systemen geführt. Hier ist die Open Source Community gefragt, Lösungen etwa in Form von Mentoring oder verstärkten Qualitätssicherungsmaßnahmen zu entwickeln. Google beschreitet bei den Summer of Code Events derartige Wege. Daraus Rückschlüsse auf die Nutzer zu ziehen ist hingegen nicht sinnvoll oder zulässig.

89 Frequently given (unsolicited) answers Damit bin ich von meinen Administratoren (bzw. deren elitärem Know-how) Die Annahme, durch Einsatz von proprietären Standardlösungen eine personelle Unabhängig- abhängig keit zu erzielen, ist nicht haltbar. Bereits mittelgroße Installationen zeichnen sich durch eine hohe Komplexität bei Schnittstellen und Systemabhängigkeiten ab, die von sachver-ständigen Dritten nur mit entsprechendem Aufwand analysiert und verstanden werden können. Open Source Lösungen zeichnen sich dem gegenüber durch offene Schnittstellen und einfache Konfigurationen aus, welche einer automatisierten Analyse leichter zugänglich sind. Schließlich findet akademische Ausbildung vermehrt mithilfe von offenen Lösungen statt. Der Zugang zu entsprechender Weiterbildung ist gegenüber proprietären Lösungen einfacher. Damit ist das am Markt verfügbare Know-how mindestens in gleichem Ausmaß vorhanden.