Proposal for Victorian Software Engineering Institute: A Strategic Approach

Assoc. Prof. Karl Reed proposed the establishment of the Victorian Software Engineering Institute to promote government policy in the information technology sector, ensure research excellence, and enhance the industry's competitive edge. The strategy focused on providing R&D support, advancing professional research capability, and creating a long-term technical viability for the IT industry through collaboration between industry and academia.

• Software Engineering
• IT Industry
• Research Excellence
• Industry-Academia Collaboration
• Competitive Edge

wier_imy Follow

Uploaded on Nov 12, 2024 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

1. A Software Engineering Institute for the Victorian Software Industry A Re-useable Case Study*... by Assoc. Prof. Karl Reed,FACS, FIE-Aust., MSc,ARMIT Chair IEEE-Computer Society Tech. Council on Software Engineering Governor, IEEE-Computer Society(1997-1999,2000-2002), Director, Computer Sys. & Software Engineering Board, ACS, Department of Computer Science & Computer Engineering, La Trobe University Hon. Visiting Professor, Middlesex University *A summary presented to the Sheffield-Hallam Univ. Feb. 2001 1

2. Why Were We Proposing VSEI? Promote government policy in information technology ensuring support for an already successful industry Ensure that the industry has a major research institute Ensure world s best practice is understood and adopted here Twenty years from now a permanent structure delivering an increased competitive edge to a major exporting industry! 2

3. Australian Political Reality Information Technology Sector --> Primary Industry share of GDP Extensive Gov t R &D for Primary Sector.. 10 Divisions of CSIRO, State R & D inst., CRC s ~15 Govt.-Industry Funded R & D Corps for Primary Industry Estimated relative short-fall ~A$700M.p.a ( 300M.p.a) Few Public sector large-scale professional research groups Universities regarding R & D as their domain.. means of cross-subsidising teaching(?) How does this compare with the UK? 3

4. What was our strategy? Forcing argument based on comparison with Primary Industry and Govt. rhetoric Linkage with industry Credible proposal . to deliver world s best practice Twenty years from now a permanent structure delivering an increased competitive edge to a major exporting industry! 4

5. Goals Guarantee the long term technical viability of a major IT industry sector the software and services industries Provide equivalent R & D support as that available to overseas competitors Provide professional research capability advancing the discipline 5

6. Industry-Academia Working Party Meeting since May 1997 Chairman Karl Reed, La Trobe University Deputy Chairman Paul Radford, Managing Director Charismatek Working party Silvio Salom, Managing Director Adacel Laurie Lock Lee, Manager Planning and Development BHPIT Robyn Lawrie, Technical Director Charismatek Alex Sawicki, Department of State Development/Multimedia Victoria Gary Stoneham, Marketing Manager MITS Sally Duncan, Project Manager Megatec Barbara O Brien, Quality Manager Megatec Bill Jacobs, Technical Director TUSC Computer Systems David Cleary, La Trobe University Special advisor Dan Marantz, Cobol Digital Observers The Preston Group Whittle Programming KCS Computer Services Clive Finkelstein, Information Engineering 6

7. Academic Partners with industry links Karl Reed, Amdahl Project (Case, Metrics, Evolvable Programming) Tharam Dillon, La Trobe University OO, Relibility, Metrics T.Y. Chen, Swinburne Univ. Tech., IVE/STC HK Testing and Software Quality Paul Bailes, Univ. Queensland. Software Maintenance Centre HK opportunity for participation 7

8. Not Seeking Silver Bullets We ve all heard of goto-less programming, structured analysis and design, CASE, object orientation, CMM, SPIN ??? all trumpeted as the solution This proposal a considered holistic response to a series of difficult problems not a quick fix ! 8

9. An Appropriate Solution A Small to Medium Enterprise Bias Only one of its kind in the world, other SEIs client domains generally not the software industry focus on embedded systems, telecom and defense aerospace pre-occupied with process issues Our objectives commercial outcomes, deliverables to industry not just academic Funding for technology transfer 9

10. Worlds Best Practice Aggregated research teams ~ researchers 40 + ~20 PG's Funded technology transfer Industry driven collaboration (including management) Cash driven budget (mostly Government) Single point of control 10

11. Scale Comparable to World's SEI's Overall A$2M pa to A$30M pa (combined Esprit is much larger) Fraunhofer Institute for Experimental Software Engineering DM20Mpa (goal) Centre de Recherche de Montreal (CRIM) C$18M pa (total) C$3M pa (software engineering) 11

12. International Funding Models Overall typically less than 50% non-government funding, often as low as 30%, sometimes zero funds often obtained from government sources other than granting agency funding models dominant mode; core funding (up to 70%) guaranteed by government agency with allowances for ramp-up 100% government funding grant based funding 12

13. International Funding Models Fraunhofer Institute for Experimental Software Engineering Fraunhofer Gesellschaft 40% regional government 10% future goal; non-Fraunhofer funding to be 70% (ramp up conditions apply) joint projects; seek 50% involvement (people preferred) 13

14. SEIs Around the World a Brief Summary Client domain generally not targeted at the software industry mainly embedded systems, telecom and defense aerospace (Korea and Taiwan and some Esprit projects are software industry) Modus Operandi networks, multi-project granting (CNRC, CRIM), academic driven, research driven, captive-client (SEI), in house, large-scale (Fraunhofer), etc 14

15. SEIs Around the World a Brief Summary Areas of investigation all areas of software engineering... Technology transfer seminars to technology trials and leverage activities (often funded by agency), experiments (PIEs), intellectual property handover Research styles single project (Esprit), short, medium, long- term, team, consortia, distributed consortia 15

16. SEIs Around the World a Brief Summary Outcomes process improvement, methodology, tools, some product (Esprit varies enormously), intellectual property Intellectual property all models; shared by partners, client owned 16

17. SEIs Around the World a Brief Summary Participants (primary funding sources) single agencies (SEI, Fruanhofer, etc), multiple agencies (European SEI), state governments (Italy, Canada, Germany), multi-national programs (Europe), very few consortia with upfront industry funding 17

18. SEIs Around the World a Brief Summary Research agenda determination agenda setting ; agency attempts to inject new technology and best of breed practice (NSF, SEI, DARPA) responsive ; industry set research agendas academic interventionist ; academia propose research projects joint ; academia and industry empiricist ; agendas derived from study of practice 18

19. SEIs Around the World Fraunhofer Institute for Experimental Software Engineering Funding Fraunhofer Gesellschaft 40% regional government 10% future goal; non-Fraunhofer funding to be 70% local government 50% of new building special ramp-up conditions apply Scale goal DM20M pa 19

20. SEIs Around the World, Centre de Recherche de Montreal (CRIM) Software Development Tools and Methods (SDTM) Funding about C$3M pa for software engineering Quebec Scale total CRIM C$18M pa Client domain embedded systems, aerospace, telecom, electricity supply, software tool builders 20

21. SEIs Around the World, Centre de Recherche de Montreal (CRIM) Software Development Tools and Methods (SDTM) Modus operandi joint academic-industry projects studies of tools, methods etc for clients specific research projects. participation sought technology monitoring projects seem small 21

22. SEIs Around the World, Centre de Recherche de Montreal (CRIM) Software Development Tools and Methods (SDTM) Areas of investigation methodology improvement re- and reverse engineering improvement of practice, including metrics, standards and SQA object orientation domain-specific architectures, reuse real-time systems, including formal methods 22

23. Some ESPRIT Research Projects Legacy Assessment Workbench (LAW) areas (aerospace, nuclear) reengineering, metrics workbench for C legacy code (safety critical systems) symbolic execution, formal methods outcomes prototypes for evaluation and adoption 23

24. Where Are We? Traditionalist s View /Bowsers that are limited /Time-To-Market web-application deployment /16 year old wunder-kinder throwing systems together /poorly designed functionality Modernist s View 4rapidly deployed functionality 4rapid evolution of systems to meet customer needs 4conventional approaches being left behind 4the old do not understand the new 24

25. To many surprises.!!!(nsf report on s/w research 1998) F1. Current software has too many surprises. The sources of surprise are poorly understood. F2. Key sources of software surprise include immature or poorly integrated software domain sciences, construction (product) principles, and engineering processes. Software research emphases have swung from process to product research, with weak coverage of domain sciences and integration. Sources of surprises... Real and apparent ambiguity in the means of representation of systems, e.i. Languages (cf 3 pages of c++ with 3 pages of government regulations)(Reed, 2000) 25

26. No surprises.!!!(nsf report on s/w research 1998) F1. Current software has too many surprises. The sources of surprise are poorly understood. Sources of surprises... Real and apparent unpredictability in behaviour... Teenagers have less trouble with PC software because they are adept at playing computer games Charles Wright, editor Melbourne Age green pages computer section 2000 Building bots that play computer games with near human competence is not that hard US researcher in AI . 26

27. By way of Illustration...Some Contradictions and confusion 1. Software Architecture.. not immutable, not always determinable a priori,multiple versions in one artefact, retrofitable . Analog with built systems not clear. 2. Software Process.. CMM vs fine-grained process independent, Time To Market vs Planned Process, Phase incompletedness, Extreme Programming. 3. Software Process...Often mandated, but not followed few detailed studies similar to production engineering (see Hess) 4. Re-use not successful, yet components industry emerging 5. Engineering & SE.. Poor choices of analogues from traditional domains, e.g. immutable components 27

28. Some Contradictions and confusion (cont d) 6. SWEBOK.. Organised body of knowledge opposed by leading SE players. 7. Prescriptive Design processes... only slowly beginning to appear, perhaps via UML. 8. Requirements Engineering... Cannot always be completed in advance..may be continuous part of the implementation process... 9. Software Crisis yet increasingly, successful large-scale applications are ubiquitous 10. High Quality training for 30 yrs.. Yet each new s/w development wave starts with a blank mind, e.g. web-based computing 11. Documentation matters but.. It s seldom actually done 28

29. Approaching Software Developers /Technico-Commercial Drivers the linkage The goal is to find a high-level, one-line statement of pressing commercial issue that maps directly on to a technology acquisition (research) agenda (map idea to common concept base accessible to highest management) / Show an economic benefit Be able to show ROI after adoption costs (equipment + training) and productivity losses due to learning curves after adoption. (improved profit) Show resolution of competitive advantage problems (beat off competitors, maintain market share) Show new market opportunities due to new products/services 29

30. Research-Commercial Mapping Defining Relevance Typical SE Research Agenda Australia ~ 1997 Technico-commercial Drivers Impact of developments in run-time platforms 1.Re-engineering and Empirical Studies of s/w Practice, Low-cost and evolving software 2.Tools and Methodologies, and Design Representation, User Interface Development 3. Re-Use, Software Productivity 4. Evolving Software, Performance Predictability 6. Object Oriented Dev. Software Product Quality Certification 7. Product Quality Measurement 8. Time-to-Market Time to Market 9. Testing 30

31. Table I - Relationship Between Technico-Commercial Issues and Research Agendas Technical- Commercial Issue Issue Implications Main Agenda Items Impact of developme nts in run- time platforms (e.g.GUI), ability to move software between platforms, need to reduce maintance Proposed Research Sub-Agendas Design reasoning recording, emperical studies of practice, software migration, impact on methodologies OUTCOMES Tools and methodologies , detailed knowledge of current practice Supports Process improvement, validation of methodologies, actual measures of s/w quality, s/w architecture, domain engineering, evolving s/w, nature of software engineering Automatic quality measurement, process improvement, nature of software engineering Add functionality to legacy Systems 1.Re-engineering and Empirical Studies of s/w Practice, /The ANSEI Technico- Comercial Driver to Research agenda mapping Low-cost and evolving software Modifiability, maintanance, techniques for designing Methodologie s for modifiable and evolving software, emperical studies of existing practice Ergonomics, characterisato n of processing, methodologies for this Methodologie s incorp. design for evolution, s/w quality , tools 3. Re-Use, 4. Evolving Software, 6. Object Oriented Development 8. Time-to-Market User Interface Developme nt Design for ergonomics, engineering based on applications data processing Methodologie s for engineering user interfaces, All methodologies, ergonomics 1. Re-engineering and Empirical Studies of s/w Practice, 3. Re-Use, 5. Engineering of User Interfaces, 6. Object Oriented Development 9. Testing 1. Re-engineering and Empirical Studies of s/w Practice, Software Productivit y Reuse, improved methods Software resuse, and methodologies explicitly including this, prescriptive methodologies , s/w architecture, improved design representation, project tracking Performance engineering, methodologies , operational mathematical methods Methodologie s generating re-usable components, maximising re-use within single projects, and maximinsing re-use of "artifacts", including design Design recording, nature of software engineering, s/w architecture, evolving software 2. Tools and Methodologies, and Design Representation, 3. Re-Use, 9. Testing Performanc e Predicatabil ity Appropriate methods for including constraints in design Methodologie s incl. new mathematical models, tools suppporting this, diagramming schemes Design recording, nature of software engineering, s/w architecture 1. Re-engineering and Empirical Studies of s/w Practice, 2.Tools and Methodologies, and Design Representation, 9. Testing 1.Re-engineering and Empirical Studies of s/w Practice, Software Product Quality Certificatio n Automatic and incremental measurement of product Program structure, metrics and language processors Tools for automatic measurement S/W architecture, design recording, nature of SE 2.Tools and Methodologies, and Design Representation, 3. Re-Use, 4. Evolving Software, 7. Product Q. Measurement 9. Testing 1.Re-engineering Empirical Studies of s/w Practice, Time to Market Improved Development techniques, Tool support, CASE As for productivity, but special emphasis on incremental delivery, and quality enhancing methodologies Methodologie s and tools, design recording s/w architecture, re- use and evolving software 2.Tools and Methodologies, and Design Representation, 3. Re-Use, 4. Evolving Software, 6. Object Oriented Dev. 7. Product Quality Measurement 8. TTM 9. Testing 31

32. Organisational Proposal Stakeholders Research Experience Government Technical Board CEO Industry Experience Industry Bus Man Management Board Technical Support Academia Personnel 32

33. Research Agendas Providing Solutions Over-Arching Goals Our research outcomes are methodologies with the following properties, these in fact become research objectives performance-based, predictable, development of systems to stated performance requirements fine-grained-prescriptive, provide precise prescriptions for steps in development improved technology and expertise for re- engineering of existing systems study of existing systems and projects, using re- engineering, design recording 33

34. Research Agendas Providing Solutions Over-Arching Goals Issues of re-use, re-use intensive and re-use based methodologies evolving software (current agenda of DARPA) object oriented methodologies, will influence, and be influenced engineering of interfaces, part of the methodology program Plus, tools that reflect this! 34

35. Characterising Time to Market Delivery schedules severely truncated compared to normal (less than 50%) How would we deal with this currently? RAD/JAD, prototyping, super programmers What would the product be like? slow, unreliable, incomplete expensive! Research goal convert this to a methodology capable of delivering quality products 35

36. Characterising Time to Market Research problems for a given project a minimum feasible delivery time tdmin cost = k tdmin quality greatly reduced competitive position increased! -n 36

37. Time to Market Project Attributes Attribute Schedule Cost Quality Standard Development (under control) controlled acceptable controlled acceptable high Time to Market (current situation) truncated unpredictable uncontrollable high usually low Time to Market (target situation) truncated predictable acceptable predictable high Customer satisfaction Runtime resources Design quality high usually resentful high minimal excessive predictable high poor high 37

38. Research Questions Schedule What is an optimal/reasonable project schedule? Is it feasible to attempt a project within a specific timeframe? Resources How can available human resources best be allocated to ensure projects succeed? 38

39. Research Questions Factors determining schedules estimating staff quality and experience methodology re-use tools 39

40. Research Activities & Outcomes Determine existing best practices collaborative work with institute partners from industry and academia Develop models, methods, tools and methodologies Assess models, methods and tools field assessments using real projects internal assessments using institute projects Disseminate knowledge gained field application of methods and tools with institute partners, publication 40

41. Research Overview Issue Schedule Resource allocation Impact on project Staff Factors Impact of schedule reduction Risk assessment Approach Data collection Process recording exemplar projects Codification of known models (eg Microsoft) Tool assessment Data collection Process recording Impact of decomposition models and parallel implementation Skill identification, fine grained classification Identification and recording of experience Outcomes Calibrated new estimating techniques Identification of risk indicators Improved planning methods planning Quality Experience Project structure Improved selection techniques Training need identification 41

42. Research Overview Issue Methodology Re-use Tools Factors Improved productivity Areas of application CASE versus lightweight Project management Analysis of existing tools and planning Languages Review and recommendation Process/design recording Approach Analysis RAD/JAD Conversion of prototyping to product development Identify essential features of usability Application generators Ultra high skill levels How to achieve this? What is re-use? Assess current re-user practices Importance of experience What do we really need here? Tool integration Outcomes High quality prototyping Components Plans Designs Test plans Tool set selection New tools Choice Identify processes 42

43. 5. Current State of Knowledge and Practice-MS vs the Rest..(cont d) history Dijkstra and THE OS in the 70 s (the lesson?)... Five people as smart as Edgar Dijkstra can do anything Reed, 1981 The first Unix effort (but what did it take for product versions) OS/360, PL/I (the lesson?) (60 s).. Very large teams can build large systems very quickly..~ x1000 person years Total volumes of functionality (e.g. OS/360) may allow partitioning..TTM issue obscured.. 43

44. Waterfall S/W Process Model Optimal task allocation, observed <1970 one or two people Feasibility Study Requirements Analysis Systems Analysis / No need for third- party readable work products! Program Design Programming / Extreme programming ? Unit Test / Private s/w process? (PeSP compliant?) System Integration System Test 44

45. Time to Market Conclusion Massive competitive advantage from time to market products with traditional high quality Necessary elements of time to market focussed processes may be accessible Detailed research by experienced staff with access to current practice is most likely to be successful 45

46. The role of re-engineering.. S/W Archaeology and S/W Architecture.... / recovery of standard architectures / identification of s/w construction practices, e.g. shifts from one programming style to another / development of maintainability and evolvability classifications for -- design methodologies architectural styles / development of maintainability and evolvability classifications for architectural styles 46

47. component semantics and concept extraction.. The role of re-engineering.. Architecture issues for the S/W Archaeologist / identification of design approaches which ensure that conceptual architectures are transferred to implementation / identification of standard mappings from conceptual to actual architectures which occur using different design approaches on different problems 47

48. Conclusion The proposal didn t win..beaten by SEA.. (Problem ridden.. Consortium) Is there a need for an SEI in the UK? Surely more than one) Do the arguments map ? How will the academic community react? (SE research in the US did not stop because CMU got the SEI ) 48

49. Technico-Commercial Problems Facing the Software Industry Hardware-software run-time environments-adding GUI etc to legacy systems Evolving software dynamically Engineered user interfaces Software productivity Design to predicted performance Time to market Software quality Testing Object orientation Net-centric systems- autonomous communicatings "agents" 49

50. Technico-Commercial Problems Facing the Software Industry Developments in hardware-software run- time environments continuing improvements in price/performance + GUI need to migrate legacy systems to these platforms need to add functionality to legacy systems on existing platforms, e.g GUI, client-server Re-engineering of legacy systems to conform to these constraints a major business opportunity 50

Load More ...