Embed Size (px)
Citation preview
James Nowotarski
13 November 2008
SE 325/425Principles and
Practices of Software Engineering
Autumn 2008
2
Topic Duration
Current event reports 20 minutes
Recap CMMI and metrics 30 minutes
Industry trends 30 minutes
*** Break
Industry trends 30 minutes
Final review 60 minutes
Today’s Agenda
3
Topic Duration
Current event reports 20 minutes
Recap CMMI and metrics 30 minutes
Industry trends 30 minutes
*** Break
Industry trends 30 minutes
Final review 60 minutes
Today’s Agenda
4
CMMI Maturity Levels
Managed(2)
Managed(2)
Defined(3)
Defined(3)
QuantitativelyManaged
(4)
QuantitativelyManaged
(4)
Optimized(5)
Optimized(5)
Initial(1)
Initial(1) Process poorly controlled and unpredictable
Process characterized for projects and is often reactive
Process characterized for the organization and is proactive
Process measured and controlled
Process improvement (“nirvana”)
5
Appraisal process
CMMI Reference model
Standard CMMI Appraisal Method for Process Improvement (SCAMPI)
Appraisal process
used by
6
CMMI Appraisal Method
TeamSelection
1
MaturityQuestionnaire
2
ResponseAnalysis
3
On-site visit
Interviews &documentreviews
4
Findingsbased on the CMMI
5
PAProfile
6
7
Appraisal Process For internal purposes:
Performed in open, collaborative environment Focuses on improving the organization’s
software process For external credential:
Performed in a more audit-oriented environment
Focuses on identifying risks associated with a contractor
Team’s recommendation will help select contractors or set fees
8
Time to Move Up
# of monthsto move tonext level
0
75
50
25
1 to 2
23 22
2 to 3
28
3 to 4
17
4 to 5
Largest observed value thatis not an outlier
75th percentile
Median (50th percentile)25th percentileSmallest observed value thatis not an outlier
Recommended time between appraisals (18-30 mos)
9
Measurement and Continuous Improvement
Continuous Improvement Measurement
10
Metrics Program Change Plan
QUALITY MANAGEMENT
Enable
Change
Technology
Process
People
Metrics Awareness Education
Metrics Network
Vital Few Metrics Definitions Vital Few Metrics Implementation
Technology Strategy
KM Support for Measurement Community of Practice
Measurement Process Improvement
Large Project Network
Metrics Strategy Commitment / Ownership
Distributed Support Units
Metrics Repository and tools
Measurement Process Definition
Roles & Responsibilities
PROGRAM MANAGEMENT
Achieve-1
Change
Sustain
Change
Achieve-2
Change
Metrics Rollout Education/Training
Pilot Project Group
Ongoing Metrics Education / Training
System Building Improvement Goals
Metrics Definition & Implementation for Delivery Centers
Metrics Embedded in System Building Methods
Dashboard metrics Implementation
Pilot Selected Projectsand Selected Delivery Centers
Enable Large Projectsand Remaining Centers
11
Measurement Program Mortality
Most programs fail, usually within 2 years
Number of companies
400
350
300
250
200
150
100
50
0
1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991
Year
Cumulative startsCumulative successes
12
Reasons for Metric Program Failure
Lack of [visible] executive sponsorship Lack of alignment with organizational goals Tendency to collect too much data Measures not calibrated, normalized, or
validated Not comparing apples-to-apples
Fear of [individual] evaluation Learning curve (e.g., function points) Cost overhead
13
Key Success Factors Ensure that measurement is part of something larger,
typically performance improvement “Trojan Horse” strategy Ensure alignment with organizational goals
Start small, iterate Strongly recommend doing a pilot test
Automate capture of metrics data Rigorously define a limited, balanced set of metrics
“Vital Few” Portfolio approach Comparability
Aggregate appropriately Focus should be on processes, not individuals
Obtain [visible] executive sponsorship Understand and address the behavioral implications
14
Final Quote
“In God we trust – All others must bring data”
W. Edwards Deming
15
Topic Duration
Current event reports 20 minutes
Recap CMMI and metrics 30 minutes
Industry trends 30 minutes
*** Break
Industry trends 30 minutes
Final review 60 minutes
Today’s Agenda
16
Industry trends
Distributed development teamsOffshoring
Aspect-oriented software development
Service orientation
17
IT Offshoring
Offshore - A location/development center in a country remote from the country in which the service or process is consumed or touches the end user or customer
Source: Gartner Group
IT Offshoring
18
IT OffshoringIT organizations and solutions providers are increasing their offshore capabilities for both maintenance and development
• Bank of America
• Ford
• NY Stock Exchange
• Motorola
• Boeing
• HSBC
• Many unpublicized
IT function of org’s• Accenture
• EDS/HP
• IBM
• Perot
• SAP
• Offshore firms, typically with local presence, e.g., Wipro, Tata, Infosys
Solutions providers• Legacy
maintenance
• New development
• Projects requiring specialized expertise, e.g.,
– Embedded software
– ERP
Types of projects
19
Reduce cost 40-50% savings
Higher quality/capability A disproportionately high percentage of CMMI Level 5 systems
development organizations are in IndiaSpeed
A “follow the sun” approach allows for 24x7 work on a project “Send the requirements docs to India at the end of the
day, and you'll have a working prototype in the morning.”
Cost, quality, and speed are the main reasons for going offshore
20
Highly capable workforce #2 in world in computer science grads (china #1, U.S. #3)
Focus on process and product quality “Quality has become an obsession with the software
developers in India” – Casimir Welch, American Society for Quality Fellows
Low labor and infrastructure costs Government commitment and support English (and other) language skills
India is the leading location for offshore sourcing
Reasons
21
India’s advantage is beginning to erode
Competition for talent is driving salaries up by as much as 30% per year
High turnover rates China, Russia, Malaysia, and Philippines are
training armies of programmers to compete with India
Increasing competition closer to the customer, e.g., “Near shore”, e.g., Mexico and Canada for U.S.
customers “On shore”, e.g., Rural Arkansas
Reasons
22
Typical division of labor
Communication project initiation requirements
Modeling analysis design
Construction code test
Deployment delivery support
Planning & Managing
PrimarilyOnshore
Both
PrimarilyOffshore
23
Sampling of issues cited by CDM students w/ experience
“…too many communication and quality issues…”
“…each location with a different process, e.g., SCM…no training for project managers [on how to make it work]”
“…lacks the incidental contacts and other informal communications that benefit a team…”
24
Industry trends
Distributed development teamsOffshoring
Aspect-oriented software development
Service orientation
25
Aspect-oriented software development (AOSD) Separation of concerns
Divide a system into parts that overlap as little as possible
Structured and object-oriented development support separation of concerns to an extent Modularity Encapsulation
Cross-cutting concerns (aka “aspects”) Cut across many modules/classes Result in duplication of code in structured and object-
oriented approaches Q. How best to handle cross-cutting aspects?
A. Aspect-oriented software development
26
Example: Cross-cutting aspect
Compo-nent 2
Compo-nent 3 Compo-
nent 4
Compo-nent 1
SW(Architectural
Model)
Typical implementation
Examples: • Logging• Security• Error handling• Tracing/Stepping
27
Example: Cross-cutting aspect
Compo-nent 2
Compo-nent 3 Compo-
nent 4
Compo-nent 1
SW(Architectural
Model)
Aspect-oriented implementation
Aspect
“Advice”“Join point”
28
AOSD Chronology
1997 – Seminal paper on the subject 2002 – U.S. Patent # 6,467,086
Xerox (Gregor Kiczales et al)
29
Gregor Kiczales video
http://video.google.com/videoplay?docid=8566923311315412414&q=engEDU
Aspect-Oriented ProgrammingRadical research in modularity
30
Jon Whipple video
http://www.youtube.com/watch?v=tzjRr3usV6I
Aspect-Oriented ModelingWhat is it and what is it good for
31
AOSD Summary
Aspect - A concern that cross-cuts the primary modularization of a software system
Aspect-oriented programming (AOP) language Extends traditional programming languages
with constructs for programming aspects Distilled to its essence, AOP provides the
ability to say, “When X happens, do Y” Aspect-oriented software development
Approaches, tools, methods to support the use of aspect-oriented concepts
32
AOSD Benefits
Improved modularityQuantifiable reduction in complexity
metrics Faster time to market Smaller code size More reliable software More maintainable software
33
AOSD Challenges
Learning curve can be steepHinders adoption
Some say it makes program comprehension more difficult
34
AOSD Players/Products
AspectJ (Eclipse Foundation) de facto standard AOP language Extension to Java Open source http://eclipse.org/aspectj
JBoss AOP (Red Hat) http://labs.jboss.com/portal/jbossaop
Spring framework The AOP-based transaction and security
libraries http://www.springframework.org
35
AOSD Market Prospects
Industry awareness has been growing rapidly over the past couple years,
Many if not most published applications are Web applications
Yet to see a major grassroots movement of “regular” developers
36
Industry trends
Distributed development teamsOffshoring
Aspect-oriented software development
Service orientation
37
Net-centric models of IT service delivery (vs. in-house delivery)
Web services, e.g., FlickrGoogle Maps
Cloud computingRun in the cloudDevelop in the cloud______ as a Service (__aaS)
Applications and Data
Middleware
Hardware/Network
System Software
______ as a Service
Public Infrastructure
Business processes
IT Infrastructure in the “Cloud”
• Amazon • EMC• Google• Microsoft
• WebEx• Netsuite• eCollege
Applications in the “Cloud”
Applications and Data
Middleware
Hardware/Network
System Software
______ as a Service
Public Infrastructure
Business processes
Ecosystem in the “Cloud”
• Salesforce.com
40
Service Oriented Architecture (SOA)
SOA “Concept Map”
41
42
SOA & Gartner Hype Cycle
43
Topic Duration
Current event reports 20 minutes
Recap CMMI and metrics 30 minutes
Industry trends 30 minutes
*** Break
Industry trends 30 minutes
Final review 60 minutes
Today’s Agenda
44
Need for Continuous Learning
“Software engineers shall participate in lifelong learning regarding the practice of their profession. They shall continually endeavor to further their knowledge of
developments in the analysis, specification, design, development, maintenance and testing of software , together with the management of the development process, to improve their knowledge of relevant standards and the law governing the software
and related documents.”
- IEEE/ACM Software Engineering Code of Ethics
45
Need for Continuous Learning
IEEE Certified Software Development Professional (CSDP)Every 5 years you must demonstrate
that you’ve kept up to date• Classes• Reading books• Seminars/Conferences
46
Technology
ProcessPeople
The software engineering discipline consists of people, process, and technology components
Remember . . .
47
THE END
Extra Slides
49
Agent-Oriented Software Engineering
Mubarak, H. (2008, September/October). Developing flexible software using agent-oriented software engineering. IEEE Software. Retrieved November 1, 2008, from IEEE Digital Library.
