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
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
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
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
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
Who Reads Methodologyand 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 2004.
Changing people’s behavior is usually the hardest part of implementing technology
Who Reads Methodologyand 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
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
Who Reads Methodology and Why
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
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 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
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
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
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
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
ProcessPeople
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
ProcessPeople
1. Assess the current state
Technology elements must be addressed also
• Tools • Standards• Reusable components• Alignment with other frameworks
24
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
Software Process Implementation Steps
25
Elements of an Implementation Plan
Sponsorship Marketing & Communication Education & Training Coordination with other initiatives Rollout schedule Ongoing Support Metrics
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 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
Software Process Implementation Steps
34
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
Software Process Implementation Steps
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
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 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
39
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
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