James Nowotarski 25 May 2004 IS 553 Advanced Systems Development Practices

2 Course Map Underpinnings. Introduction. Essentials Content. Rational Unified Process. Agile Implementation. Metrics. CMM. Distributed development. Tools & training Briefings (Term Papers) Assignments Quizzes Week (RUP)(Agile)(CMM) (Distr. Dev.)

3 Understand who uses methodology and why Understand key strategies and issues affecting methodology deployment, adoption, and usage Be able to outline a methodology deployment plan Be aware of development tools “big picture” Today’s Objectives

4 Topic Duration Quiz 4 recap15 minutes Who reads methodology and why15 minutes Deployment, adoption, use60 minutes *** Break15 minutes Current Event Reports30 minutes Development tools60 minutes Today’s Agenda

5 Topic Duration Quiz 4 recap15 minutes Who reads methodology and why15 minutes Deployment, adoption, use60 minutes *** Break15 minutes Current Event Reports30 minutes Development tools60 minutes Today’s Agenda

6 Factors to Determine Location (Gartner Group) FactorOn-SiteOffshore User interactionHighLow MethodologyIterativeWaterfall Technology and skills availability Strong local availabilityScarce/Expensive locally Systems/Application integration HighLow Immigration policiesOpen locallyClosed Cost objectivesWeakStrong Quality objectivesNo change neededImprovement desired Scale of offshore resources LowHigh Requirements definition Loose/ambiguousComplete/Well-defined

7 Topic Duration Quiz 4 recap15 minutes Who reads methodology and why15 minutes Deployment, adoption, use60 minutes *** Break15 minutes Current Event Reports30 minutes Development tools60 minutes Today’s Agenda

8 Technology Process People The focus of IS 553 has been the process component of systems development capability IS 553 Who Reads Methodology and Why

9 Technology Process People Today, we will focus on the People and Technology components Who Reads Methodology and Why

10 Technology Process People People – The most difficult component Who Reads Methodology and Why

11 “A lot of times, technology is hyped and sold and somebody buys it. But what isn’t hyped enough is how difficult it is to implement the technology so that it has an impact” – Tim Waterloo, president of Glen Ellyn consulting firm Oak Enterprises, quoted in Crain’s Chicago Business, 10 May Changing people’s behavior is usually the hardest part of implementing technology Who Reads Methodology and Why

12 Who Reads Methodology and Why Study of 1000 practitioners by Prof. Gezinus Hidding, Loyola University (mid-1990’s) Practitioners seldom “read” the methodology But when they do, it is to: learn about something new (training) look something up that they once knew or want to confirm (reference) Different needs depending on role

13 TrainingReference Planning8%36% Selling6%20% Doing6%13% Managing2%9% Methodology is used mostly by planners and mostly for reference purposes Source: Gezinus Hidding, Loyola University Roles How Used Who Reads Methodology and Why

14 ProcessArtifactGuidelineConcept Planning43%37%14%7%7% Selling48%35%12%5% Doing40%34%16%10% Managing42%34%18%6% Process descriptions and artifacts are the most valuable types of REFERENCE information Source: Gezinus Hidding, Loyola University Who Reads Methodology and Why Percentage of time Planners REFERENCE Process info

15 Who Reads Methodology and Why Information needs of planners (“crucial target”) need for speed summary overviews of processes and artifacts Information needs of doers artifact samples guidelines/techniques

16 Topic Duration Quiz 4 recap15 minutes Who reads methodology and why15 minutes Deployment, adoption, use60 minutes *** Break15 minutes Current Event Reports30 minutes Development tools60 minutes Today’s Agenda

17 Why is Software Process Implementation So Hard? Process change affects behavior Cultural barriers Examples: “Cowboy culture” will resist structure Hierarchical culture will resist XP Target audience lacks time “Death by 1000 initiatives” Not a “sexy” topic Method/1 = “Methadone”

18 Software Process Implementation Steps 1.Assess the current state 2.Set (or revise) goals 3. Identify risks 4.Plan the process implementation 5.Execute the process implementation Current process New process Completely Implemented 6.Evaluate the process implementation

19 Software Process Implementation Steps 1.Assess the current state 2.Set (or revise) goals 3. Identify risks 4.Plan the process implementation 5.Execute the process implementation Current process New process Completely Implemented 6.Evaluate the process implementation

20 1. Assess the current state AssetsDeploymentUsage Bus. Modeling Requirements Analysis & Design etc. One approach to assessment: Look at assets, deployment of assets, and usage of assets Scorecard/Gap Analysis

21 1. Assess the current state Assets: Do we have good stuff? Deployment: Do people know about the assets? Do people know what to do with the assets? Usage: Are people using the assets on projects?

22 Technology Process People 1. Assess the current state People - Perhaps the most difficult piece for a technology person Ownership/Sponsorship Motivation Rewards/Incentives Training Physical work environment Roles, reporting relationships Performance measurement

23 Technology Process People 1. Assess the current state Technology elements must be addressed also Tools Standards Reusable components Alignment with other frameworks

24 1.Assess the current state 2.Set (or revise) goals 3. Identify risks 4.Plan the process implementation 5.Execute the process implementation Current process New process Completely Implemented 6.Evaluate the process implementation Software Process Implementation Steps

25 Elements of an Implementation Plan Sponsorship Marketing & Communication Education & Training Coordination with other initiatives Rollout schedule Ongoing Support Metrics

26 Sponsorship Executive level Visibility Accountability Elements of an Implementation Plan

27 Marketing & Communication Need to be aware of where target audience is: Misinformed Unaware Aware Understand Believe Action Err on side over-communication Relate to business performance objectives Types of materials? (discuss) Elements of an Implementation Plan

28 Education & Training Train-the-Trainer Rollout training (one-time event) For the unwashed masses “Retread” training Ongoing training curriculum Levels to target User Developer Manager Executive Elements of an Implementation Plan

29 Elements of an Implementation Plan Coordination with other initiatives Align vocabulary, practices Examples: Performance evaluations IT strategy Allow others to “invoke” methodology Analogous to Microsoft publishing API’s in a Software Developer Kit (SDK)

30 Elements of an Implementation Plan Rollout schedule Incremental approach recommended Pilot is usually a good idea Shake out Success story will help with takeup by others Especially critical if risks are great “the most effective way to introduce process and tools”

31 Elements of an Implementation Plan Ongoing Support Local experts Central help desk Need to capture feedback (“experience factory”) Fixes Enhancements Innovations Systems development metrics

32 Elements of an Implementation Plan Metrics (on the implementation process) Training time Awareness Usage Local experts time allocation Help desk requests Errors/Enhancements

33 1.Assess the current state 2.Set (or revise) goals 3. Identify risks 4.Plan the process implementation 5.Execute the process implementation Current process New process Completely Implemented 6.Evaluate the process implementation Software Process Implementation Steps

34 1.Assess the current state 2.Set (or revise) goals 3. Identify risks 4.Plan the process implementation 5.Execute the process implementation Current process New process Completely Implemented 6.Evaluate the process implementation Software Process Implementation Steps

35 Phase 1 Phase 2Phase 3Phase 4 Implementing a process is a project The group of people working on implementing the process should be dedicated Software Process Implementation Steps

36 Implementation Key Success Factors Involve systems developers in assessing current process Implement appropriate tools Software development tools Methodology related tools configuration/customization browsing estimating project planning/management workflow management Communicate, communicate, communicate Visible executive support Positive track record (i.e., no “busts”) Incremental/Iterative implementation of methodology For XP, start with testing or planning

37 Usual Causes of Implementation Failure No clear business objective Lack of visible leadership/sponsorship Lack of adequate training Lack of effective communication Death by 1000 initiatives New/Changed roles not implemented Fail to account for different information needs of “planners” and “doers” Too detailed for planners Not enough detail for doers

38 Topic Duration Quiz 4 recap15 minutes Who reads methodology and why15 minutes Deployment, adoption, use60 minutes *** Break15 minutes Current Event Reports30 minutes Development tools60 minutes Today’s Agenda

39 Topic Duration Quiz 4 recap15 minutes Who reads methodology and why15 minutes Deployment, adoption, use60 minutes *** Break15 minutes Current Event Reports30 minutes Development tools60 minutes Today’s Agenda

40 Configuration Management Release Management Environment Management Problem Management Information Management Process Management Quality Mgmt Program & Project Mgmt System Building Security Management Productivity Collaboration Collaborative tools enable groups of people to communicate and to share information. , video and audio conference calls, and instant messaging are examples of these tools. Configuration Management tools include the version control, migration control and change control of code and documentation. Environment Management tools support the operation of the development environment, such as help desk support and backup/recovery activities. Information Management tools organize and manage information used by other tools. Information types may include code, documentation, test scripts and data and database designs. Problem Management tools assist problem tracking and solution processes. Process Management tools enforce the correct sequencing of tasks and tools in conformance with a pre-defined methodology. Productivity tools provide the basic functionality required to create documents, spreadsheets, and simple graphics or diagrams. Program and Project Management tools assist project planning and help track project status according to plan. Quality Management tools help gather and present product- and process- related metrics, and includes tools like CQMA. Release Management tools manage project dependencies between multiple releases and between different teams working on the same release. Security Management tools secure the development environment and serve as components in the security layer of the solution being developed. System Building tools constitute the core of the development architecture and are used to design, build, and test the system. Tools Framework – Overview Source: Accenture

41 Analysis & DesignReverse Engineering Packaged Component Integration ConstructionTest Test Data Management Test Data Manipulation Test Planning Test Execution Emulation Tools Test Coverage Measurement Test Result Comparison SIR Management Performance Management Construction Source Code Editor Compiler/Linker/Interpreter Source Code Debugger QA Utilities Media Content Creation Code/Object Libraries Generation Packaged Component Integration Customization Reverse Engineering Interactive Navigation Graphical Representation Extraction Repository Population Data Name Rationalization Restructuring Analysis & Design Data Modeling Process Modeling Event Modeling Performance Modeling Object Modeling Component Modeling Prototyping Database Design Application Logic Design Presentation Design Communication Design Reuse Support Usability Test System Building

42 System Building J2EE IBM has leadership role Rational acquisition in late 2002 Integration of Rational tools with WebSphere application development tools.NET Microsoft announcing its Visual Studio Team System week of 5/24/04 Tools from requirements analysis to modeling, design, development, testing, and maintenance Features a tool, code-named Whitehorse, that will allow programmers to construct an application from a visual representation (model-driven) Support for service-oriented architectures (aka web services) “Drag, drop, and connect” Application development (AD) for most enterprises' business solutions has become a "two-horse race" — between.NET and Java 2 Platform, Enterprise Edition (J2EE)

43 System Building Model-driven: Use business terminology to describe what the software is to do Higher level of abstraction than code No manual translation required IBM, Microsoft, Borland all pursuing Increasing emphasis on model-driven approaches

44 System Building By 2007, packaged applications and outsourced development will be the main source of new applications Result: De-skilling of in-house application development organizations Application development is increasingly about assembly rather than coding

45 System Building Example: CICS/Cobol with IMS or DB2 as DBMS Primary approach is to “wrap” legacy code with well-defined, component-based interfaces One of the biggest application development challenges is to address the huge amount of legacy code

46 System Building 80% of new code development is Java and Visual Basic The number of professional VB developers is approximately 2x the number of professional Java developers Between 2000 and 2008, number of worldwide Java developers to grow from 1M to 5M

47 System Building C# demand will increase, C++ and Cobol will decline Future demand Current developer base C# VB Java C++ Cobol PowerBuilder Pascal Smalltalk Delphi Source: Gartner Group

48 System Building Dubbed “The Magnificent Two” IBM Visual Age for Java Borland JBuilder For Java, 35-40% of enterprises use the tools of Borland and IBM

49 System Building JavaScript is the most heavily-used scripting language Future demand Current developer base VBScript JavaScript Perl ColdFusion JScript Python Source: Gartner Group

50 System Building Extensible, open source architecture Based on Java and J2EE Foundation for variety of plug-in modules targeted at application development and deployment IBM has been main driver Needs better balance of non-IBM members Name implies anti-Sun, anti-standards (eclipse=blot out sun) Sun has its own open source Java architecture called Netbeans.org The Eclipse Foundation has far-reaching potential

51 Reminder: Timing of Presentations June 1June 8 Bird/Burton Herbst Jain Johnson Limjoco/Thong-Ngam Scoz Shakeel Chung Craig Dakshi Falcon Haqi Stoler Therdwikrant