Advanced Design of Software Architectures 1

1
Advanced Design of Software Architectures - 1

• 213540
• 2004/2005 Quarter 2
• Klaas van den Berg
• Version ADSA1 2004 L02 v02

2
Outline

• Summary
• Laws of Software Evolution
• Change and Software Process Maturity (CMM-I)
• Change and Software Process Development
• Renovation of Legacy Systems
• Essay Topics
• References

3
Summary

• Co-Evolution Software/Business
• Software Process Standards
• Software Maintenance Categories/Taxonomies
• Software Maintenance Process

4
Innovations Are Processes Too

• (after Osterweil, 1987)
• Innovations in measured and controlled processes

5
ISO/IEC 12207

• Maintenance
• Categories
• Process

(ISO/IEC 12207, 1999)
6
Outline

• Summary
• Laws of Software Evolution
• Change and Software Process Maturity (CMM-I)
• Change and Software Process Development
• Renovation of Legacy Systems
• Essay Topics
• References

7
Lehmans Laws of SW Evolution

• Eight Laws (first laws in 1974 Lehman et al.,
  2000)
• FEAST Project Feedback, Evolution And Software
  Technology
• 1. Continuing Change
• Software systems must be continually adapted else
  they become progressively less satisfactory in
  use
• 2. Increasing Complexity
• As a software system evolve its complexity
  increases unless work is done to maintain or
  reduce it
• 3. Self Regulation
• Software system evolution processes are
  self-regulating

8
Lehmans Laws of SW Evolution

• 4. Conservation of Organizational Stability
• Unless feedback mechanisms are appropriately
  adjusted, average effective global activity rate
  in an evolving software system tends to remain
  constant over product life time
• 5. Conservation of Familiarity
• The incremental growth and long term growth rate
  of software systems tend to decline
• 6. Continuing Growth
• The functional capability of software systems
  must be continually increased to maintain user
  satisfaction over the system lifetime

9
Lehmans Laws of SW Evolution

• 7. Declining Quality
• Unless rigorously adapted to take into account
  changes in the operational environment, the
  quality of software systems will appear to be
  declining
• 8. Feedback System
• Software evolution processes are multi-level,
  multi-loop, multi-agent feedback systems

10
Outline

• Summary
• Laws of Software Evolution
• Change and Software Process Maturity (CMM-I)
• Change and Software Process Development
• Renovation of Legacy Systems
• Essay Topics
• References

11
Change in Software Processes

• CMM
• Software Engineering Institute (SEI)
• Capability Maturity ModelSM for Software, Version
  1.1 (Paulk et al., 1993). Capability Maturity
  Model Guidelines for Improving the Software
  Process (Paulk et al., 1995).
• SEI / SW-CMM
• SEI / SW-CMMI (CMM Integration)
• http//www.sei.cmu.edu/cmmi/

12
CMM Process Maturity Levels
13
Process Maturity Levels
14
Maturity Levels

• 1) Initial
• The software process is characterized as ad hoc,
  and occasionally even chaotic. Few processes are
  defined, and success depends on individual
  effort.
•  2) Repeatable
• Basic project management processes are
  established to track cost, schedule, and
  functionality. The necessary process discipline
  is in place to repeat earlier successes on
  projects with similar applications.  
• 3) Defined
• The software process for both management and
  engineering activities is documented,
  standardized, and integrated into a standard
  software process for the organization. All
  projects use an approved, tailored version of the
  organization's standard software process for
  developing and maintaining software.

15
Maturity Levels

• 4) Managed
• Detailed measures of the software process and
  product quality are collected. Both the software
  process and products are quantitatively
  understood and controlled.
• 5) Optimizing
• Continuous process improvement is enabled by
  quantitative feedback from the process and from
  piloting innovative ideas and technologies.

16
(Key) Process Areas - KPAs
17
KPAs Level 2 (selection)

• Requirements Management
• establish a common understanding between the
  customer and the software project of the
  customer's requirements that will be addressed by
  the software project.
• Software Project Planning
• establish reasonable plans for performing the
  software engineering and for managing the
  software project.
• Software Project Tracking and Oversight
• establish adequate visibility into actual
  progress so that management can take effective
  actions when the software project's performance
  deviates significantly from the software plans.
• Software Quality Assurance
• provide management with appropriate visibility
  into the process being used by the software
  project and of the products being built.
• Software Configuration Management
• establish and maintain the integrity of the
  products of the software project throughout the
  project's software life cycle.

18
KPAs Level 3 (selection)

• Integrated Software Management
• integrate the software engineering and management
  activities into a coherent, defined software
  process that is tailored from the organization's
  standard software process and related process
  assets
• Software Product Engineering
• consistently perform a well-defined engineering
  process that integrates all the software
  engineering activities to produce correct,
  consistent software products effectively and
  efficiently
• Peer Reviews
• remove defects from the software work products
  early and efficiently. An important corollary
  effect is to develop a better understanding of
  the software work products and of the defects
  that can be prevented.

19
KPAs Level 4 5

• Level 4
• Quantitative Process Management
• control the process performance of the software
  project quantitatively.
• Software Quality Management
• develop a quantitative understanding of the
  quality of the project's software products and
  achieve specific quality goals.
• Level 5
• Defect Prevention
• identify the causes of defects and prevent them
  from recurring. The software project analyzes
  defects, identifies their causes, and changes its
  defined software process

20
Change in CMM

• Level 5 Optimizing
• Continuous process improvement is enabled by
  quantitative feedback from the process and from
  piloting innovative ideas and technologies.
• Key Process Areas
• Technology Change Management
• identify beneficial new technologies (i.e.,
  tools, methods, and processes) and transfer them
  into the organization in an orderly manner,
• Process Change Management
• continually improve the software processes used
  in the organization with the intent of improving
  software quality, increasing productivity, and
  decreasing the cycle time for product
  development.

21
CMMI

• Capability Maturity Model Integration
• Maturity Levels Process Areas (PA)
• Two versions
• Staged Model
• Assessment Result Maturity Level (1..5)
• Continuous Model
• Assessment Result Capability Level Profile
• CLP a list of process areas and their
  corresponding capability levels. The profile may
  be an achievement profile when it represents the
  organization's progress for each process area
  while advancing through the capability levels.
  Or, the profile may be a target profile when it
  represents an objective for process improvement.

22
Capability Level

• Achievement of process improvement within an
  individual process area. A capability level is
  defined by the appropriate specific and generic
  practices for a process area.
• Levels
• 0 Incomplete
• 1 Performed
• 2 Managed
• 3 Defined
• 4 Quantitatively Managed
• 5 Optimizing

23
CMMI

• Capability Maturity Model Structure

PA GG
SG
CO AB DI VE
SP GP
24
CMMI

• Level 5 Optimizing
• PA Organizational Innovation and Deployment
• The purpose of Organizational Innovation and
  Deployment is to select and deploy incremental
  and innovative improvements that measurably
  improve the organization's processes and
  technologies. The improvements support the
  organization's quality and process-performance
  objectives as derived from the organization's
  business objectives
• PA Causal Analysis and Resolution
• The purpose of Causal Analysis and Resolution is
  to identify causes of defects and other problems
  and take action to prevent them from occurring in
  the future.

25
Practice-to-Goal Relationship

• SG 1 Select Improvements
• SP 1.1 Collect and Analyze Improvement Proposals
• SP 1.2 Identify and Analyze Innovations
• SP 1.3 Pilot Improvements
• SP 1.4 Select Improvements for Deployment
• SG 2 Deploy Improvements
• SP 2.1 Plan the Deployment
• SP 2.2 Manage the Deployment
• SP 2.3 Measure Improvement Effects
• SG Specific Goal
• SP Specific Practice

26
Practice-to-Goal Relationship

• GG 3 Institutionalize a Defined Process
• GP 2.1 (CO 1) Establish an Organizational Policy
• GP 3.1 (AB 1) Establish a Defined Process
• GP 2.2 (AB 2) Plan the Process
• GP 2.3 (AB 3) Provide Resources
• GP 2.4 (AB 4) Assign Responsibility
• GP 2.5 (AB 5) Train People
• .
• CO Commitment to Perform
• AB Ability to Perform

27
Practice-to-Goal Relationship

• GG 3 Institutionalize a Defined Process
• .
• GP 2.6 (DI 1) Manage Configurations
• GP 2.7 (DI 2) Identify and Involve Relevant
  Stakeholders
• GP 2.8 (DI 3) Monitor and Control the Process
• GP 3.2 (DI 4) Collect Improvement Information
• GP 2.9 (VE 1) Objectively Evaluate Adherence
• GP 2.10(VE 2) Review Status with Higher Level
  Management
• DI Directing Implementation
• VE Verifying Implementation

28
Outline

• Summary
• Laws of Software Evolution
• Change and Software Process Maturity (CMM-I)
• Change and Software Process Development
• Renovation of Legacy Systems
• Essay Topics
• References

29
Software Development Processes

• Plan-driven methods (Boehm Turner, 2004)
• Characterized by a systematic engineering
  approach through a series of representations from
  requirements, design to finished code, with
  strong documentation and traceability and a well
  defined process
• ISO 12207, CMM, Personal/Team Software
  Process,Rational Unified Process
• Heavy weight

30
Software Development Processes

• Agile methods (Boehm Turner, 2004)
• Characterized by short iterative cycles, user
  involvement to establish, prioritize, and verify
  requirements , and self-organizing teams
• Extreme Programming (XP), Adaptive Software
  Development (ASD),
• Light weight

31
Agile Software Development

• Principles Agile Manifesto
• Individuals and interactions over processes and
  tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• http//agilemanifesto.org/

32
Agile Software Development

• Characteristics
• Incremental small software releases
• Cooperative close customer and developer
  interaction
• Straightforward easy to learn and to modify
• Adaptive react to last moment changes
• (Abrahamsson, et al., 2003)

33
ASD Examples

• Scrum
• 1995, Schwaber
• DSDM
• 1995, Dynamic Systems Development Method,
  Stapleton
• Crystal
• 1998, Cockburn
• XP
• 1999, eXtreme Programming, Beck
• ASD
• 2000, Adaptive Software Development, Highsmith
• FDD
• 2002, Feature-Driven Development, Palmer
  Felsing
• AM
• 2002, Agile Modeling, Ambler

34
Plan-Driven versus Agile

• Balancing plan-driven and agility
• Dimensions for selection
• Risk-based method engineering
• (Boehm Turner, 2004)
• Agile Processes suitable for
• Small projects, less critical, high change,
  experts, many degrees of freedom
• Based on Analysis of 5 Project Dimensions

35
Plan-Driven versus Agile

• Project Dimensions
• Dynamism
• Rate of requirements changes Requirements /
  month
• Size
• Number of personnel in team
• Criticality
• Loss due to impact of defects
• Personnel
• Expertise Experts in team
• Culture
• Freedom vs procedures Defined roles

36
Project Dimensions
Personnel (expertise) low
Criticality high
Dynamism low
Assessment
Agile
defined Culture
large Size
Plan-driven
37
Risk-based method engineering

• Environmental risks
• Technology uncertainties
• Many diverse stakeholders
• Complexity of system
• Agile risks
• Scalability and criticality
• Necessity of design
• Personnel turnover
• Lack of skilled agile people
• Plan-driven risks
• Rapid change
• Need for rapid results
• Emergent requirements
• Lack of skilled plan-driven people

38
Process Characteristics

• Application
• Primary goals, Size, Environment
• Management
• Customer relations, Planning control,
  Communication
• Technical
• Requirements, Development, Testing
• Personnel
• Customers, Developers, Culture
• (Boehm Turner, 2004)

39
Outline

• Summary
• Laws of Software Evolution
• Change and Software Process Maturity (CMM-I)
• Change and Software Process Development
• Renovation of Legacy Systems
• Essay Topics
• References

40
Software Evolution Renovation

• Legacy software is critical software that cannot
  be modified efficiently (Gold, 1998)
• Reengineering is the systematic transformation
  of an existing system into a new form, to realize
  quality improvements in operation, system
  capability, functionality, performance, or
  evolvability at a lower cost, schedule, or risk
  to the customer. (Tilley, 1995)

41
Chikovsky Cross, 1990

• Reverse engineering The process of analyzing a
  subject system to identify the systems components
  and their interactions and to create
  representations of the system in another form or
  a higher level of abstraction
• Forward engineering The traditional process of
  moving from high level abstractions and logical
  implementation-independent designs to the
  physical implementation of a system
• RestructuringThe transformation from one
  representation form to another, at the same
  relative abstraction level, while preserving the
  subject systems external behavior (functionality
  and semantics)

42
Outline

• Summary
• Laws of Software Evolution
• Change and Software Process Maturity (CMM-I)
• Change and Software Process Development
• Renovation of Legacy Systems
• Essay Topics
• References

43
Conclusion

• Laws of Software Evolution
• Lehmans laws
• Change as Manageable Processes
• Process Maturity Levels / Key Process Areas
• Customizing Software Development Processes
• Agile versus Plan-driven development
• Evolving Legacy Ssytem
• Renovation processes

44
Conclusion

• Essay topics

• Describe strengths and weaknesses of
• References on TeleTOP