James Nowotarski 25 May 2004 IS 553 Advanced Systems Development Practices

James Nowotarski

25 May 2004

IS 553Advanced Systems

Development Practices

2

Course Map

Underpinnings. Introduction. Essentials

Content. Rational Unified Process. Agile

Implementation. Metrics. CMM. Distributed development. Tools & training

Briefings (Term Papers)

1 2 3 4 6 7 8 9 10 115

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 recap 15 minutes

Who reads methodology and why 15 minutes

Deployment, adoption, use 60 minutes

*** Break 15 minutes

Current Event Reports 30 minutes

Development tools 60 minutes

Today’s Agenda

5

Topic Duration







Today’s Agenda

6

Factors to Determine Location (Gartner Group)

Factor On-Site Offshore

User interaction High Low

Methodology Iterative Waterfall

Technology and skills availability

Strong local availability Scarce/Expensive locally

Systems/Application integration

High Low

Immigration policies Open locally Closed

Cost objectives Weak Strong

Quality objectives No change needed Improvement desired

Scale of offshore resources

Low High

Requirements

definition

Loose/ambiguous Complete/Well-defined

7

Topic Duration







Today’s Agenda

8

Technology

ProcessPeople

The focus of IS 553 has been the process component of systems development capability

IS 553

Who Reads Methodologyand Why

9

Technology

ProcessPeople

Today, we will focus on the People and Technology components


10

Technology

ProcessPeople

People – The most difficult component


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 2004.

Changing people’s behavior is usually the hardest part of implementing technology


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

Training Reference

Planning 8% 36%

Selling 6% 20%

Doing 6% 13%

Managing 2% 9%

Methodology is used mostly by planners and mostly for reference purposes

Source: Gezinus Hidding, Loyola University

Roles

How Used


14

Process Artifact Guideline Concept

Planning 43% 37% 14% 7%

Selling 48% 35% 12% 5%

Doing 40% 34% 16% 10%

Managing 42% 34% 18% 6%

Process descriptions and artifacts are the most valuable types of REFERENCE information

Source: Gezinus Hidding, Loyola University


Percentage of time Planners REFERENCE Process info

15


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







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 state2. Set (or revise) goals

3. Identify risks

4. Plan the process implementation

5. Execute the process implementation

Current process

New processCompletelyImplemented

6. Evaluate the process implementation

19



3. Identify risks



Current process



20

1. Assess the current state

Assets Deployment Usage

Bus. Modeling

Requirements

Analysis & Design

etc.

One approach to assessment: Look at assets, deployment of assets, and usage of assets

Scorecard/Gap Analysis

21


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

ProcessPeople


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

ProcessPeople


Technology elements must be addressed also

• Tools • Standards• Reusable components• Alignment with other frameworks

24


3. Identify risks



Current process




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


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)


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


29


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


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


Ongoing Support• Local experts• Central help desk• Need to capture feedback (“experience

factory”)• Fixes• Enhancements• Innovations• Systems development metrics

32


Metrics (on the implementation process)• Training time• Awareness • Usage• Local experts time allocation• Help desk requests• Errors/Enhancements

33


3. Identify risks



Current process




34


3. Identify risks



Current process




35

Phase 1 Phase 2 Phase 3 Phase 4

Implementing a process is a project

The group of people working on implementing the process should be dedicated


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







Today’s Agenda

39

Topic Duration







Today’s Agenda

40

Configuration Management

Release Management

Environment Management

Problem Management

Information Management

Process Management

QualityMgmt

Program& ProjectMgmt

System Building

Security Management

Pro

du

ctiv

ity

Co

llab

ora

tio

n

Collaborative tools enable groups of people to communicate and to share information. E-mail, 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 & Design

Reverse Engineering

Packaged Component Integration

Construction

Test

TestTest

Test Data Management

Test Data Manipulation

Test Planning

Test Execution

Emulation Tools

Test Coverage Measurement

Test Result Comparison

SIR Management

Performance Management

ConstructionConstructionSource Code Editor

Compiler/Linker/Interpreter

Source Code Debugger

QA Utilities

Media Content Creation

Code/Object Libraries

Generation

Packaged Component IntegrationPackaged Component Integration

Customization

Reverse EngineeringReverse Engineering

Interactive Navigation

Graphical Representation

Extraction

Repository Population

Data Name Rationalization

Restructuring

Analysis & DesignAnalysis & 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

Currentdeveloperbase C#

VB

Java

C++

Cobol

PowerBuilderPascalSmalltalkDelphi

Source: Gartner Group

48

System Building

Dubbed “The Magnificent Two” IBM Visual Age for JavaBorland 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

Currentdeveloperbase

VBScript

JavaScript Perl

ColdFusionJScriptPython

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 PresentationsJune 1 June 8

Bird/Burton

Herbst

Jain

Johnson

Limjoco/Thong-Ngam

Scoz

Shakeel

Chung

CraigDakshi

Falcon

Haqi

StolerTherdwikrant

Documents

James Nowotarski 25 May 2004 IS 553 Advanced Systems Development Practices