James Nowotarski

1
SE 325/425Principles and Practices of Software
EngineeringAutumn 2008

• James Nowotarski
• 13 November 2008

2
Todays Agenda

• 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

3
Todays Agenda

• 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

4
CMMI Maturity Levels
Process improvement (nirvana)
Process measured and controlled
Process characterized for the organization and is
proactive
Process characterized for projects and is often
reactive
Initial (1)
Process poorly controlled and unpredictable
5
Appraisal process
6
CMMI Appraisal Method
Team Selection
1
7
Appraisal Process

• For internal purposes
• Performed in open, collaborative environment
• Focuses on improving the organizations software
  process
• For external credential
• Performed in a more audit-oriented environment
• Focuses on identifying risks associated with a
  contractor
• Teams recommendation will help select
  contractors or set fees

8
Time to Move Up
of months to move to next level
75
50
Largest observed value that is not an outlier
28
75th percentile
23
Recommended time between appraisals (18-30 mos)
22
25
17
Median (50th percentile)
25th percentile
Smallest observed value that is not an outlier
0
1 to 2
4 to 5
2 to 3
3 to 4
9
Measurement and Continuous Improvement
Continuous Improvement
Measurement
10
Metrics Program Change Plan
Enable Large Projects and Remaining Centers
Pilot Selected Projects and Selected Delivery
Centers
People
Process
Metrics Embedded in System Building Methods
Technology
QUALITY MANAGEMENT
PROGRAM MANAGEMENT
11
Measurement Program Mortality
Most programs fail, usually within 2 years
Number of companies
400
Cumulative starts Cumulative successes
350
300
250
200
150
100
50
0
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
Year
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
Todays Agenda

• 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

16
Industry trends

• Distributed development teams
• Offshoring
• Aspect-oriented software development
• Service orientation

17
IT Offshoring
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

18
IT Offshoring

• IT organizations and solutions providers are
  increasing their offshore capabilities for both
  maintenance and development

19
Cost, quality, and speed are the main reasons for
going offshore

• Reduce cost
• 40-50 savings
• Higher quality/capability
• A disproportionately high percentage of CMMI
  Level 5 systems development organizations are in
  India
• Speed
• 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.

20
India is the leading location for offshore
sourcing
Reasons

• 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

21
Indias advantage is beginning to erode
Reasons

• 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

22
Typical division of labor
Planning Managing
Communication project initiation requirements
Modeling analysis design
Construction code test
Deployment delivery support
23
Sampling of issues cited by CDM students w/
experience

• too many communication and quality issues
• each location with a different process, e.g.,
  SCMno 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 teams
• Offshoring
• 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
Typical implementation
Compo- nent 3
Compo- nent 2
Compo- nent 4
Compo- nent 1

• Examples
• Logging
• Security
• Error handling
• Tracing/Stepping

27
Example Cross-cutting aspect
Aspect-oriented implementation
Compo- nent 3
Compo- nent 2
Compo- nent 4
Aspect
Compo- nent 1
Advice
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
Aspect-Oriented Programming Radical research in
modularity

• http//video.google.com/videoplay?docid8566923311
  315412414qengEDU

30
Jon Whipple video
Aspect-Oriented Modeling What is it and what is
it good for

• http//www.youtube.com/watch?vtzjRr3usV6I

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 modularity
• Quantifiable reduction in complexity metrics
• Faster time to market
• Smaller code size
• More reliable software
• More maintainable software

33
AOSD Challenges

• Learning curve can be steep
• Hinders 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 teams
• Offshoring
• Aspect-oriented software development
• Service orientation

37
Net-centric models of IT service delivery (vs.
in-house delivery)

• Web services, e.g.,
• Flickr
• Google Maps
• Cloud computing
• Run in the cloud
• Develop in the cloud
• ______ as a Service (__aaS)

38
______ as a Service
Business processes
Applications and Data
Middleware
System Software
Hardware/Network
Public Infrastructure
39
______ as a Service
Business processes
Applications and Data
Middleware
System Software
Hardware/Network
Public Infrastructure
40
Service Oriented Architecture (SOA)
41
SOA Concept Map
42
SOA Gartner Hype Cycle
43
Todays Agenda

• 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

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 youve
  kept up to date
• Classes
• Reading books
• Seminars/Conferences

46
Remember . . .
The software engineering discipline consists of
people, process, and technology components
47
THE END
48
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.