Strategic Software Engineering

1
Strategic Software Engineering
November 14, 2006 ISM6930 Fall 2006

• Section One The Process Its Models

Presented by Beth Myers Matthew Reilly
2
Introduction

• Strategic Software Engineering An
  Interdisciplinary Approach
• By Fadi P. Deek,James A.M. McHugh Osama M.
  Eljabiri
• Published in 2005 by Auerbach Publications

3
Our Objectives

• Introduction
• Section One The Process Its Models
• Basic Planning Control
• Tools, Objects Reuse
• Process Improvement
• Reinventing How It Is Done
• An Assessment of Process Life-Cycle Models

4
Software Development Todays Business
Environment

• Mission Criticality of Software in Business Today
• Competitive Unpredictable Nature of Todays
  Business Environment
• Importance for SW developers, project managers
  and business organizations to understand and
  implement software environments that are
• Diversified
• Multidisciplinary

5
A New View of SW Engineering

• Past View
• Primarily technical
• Scientifically focused process
• Proposed View for Today
• Strategic
• Business-Oriented
• Interdisciplinary
• Tool for achieving business goals in
  collaboration with all the affected stakeholder
  communities

6
Books Objectives

• To present the technical and scientific aspects
  of development in an accessible way, while
  critically reviewing the SW development models
  and process
• To consider how SW has been created in the past,
  with what shortcomings, as well as what new
  paradigms are emerging that reflect how
  development should be done
• To present a strategic, business-oriented
  assessment of the forces that have influenced the
  development of SW process models in order to
  better understand what measures or direction
  should be taken to further improve them
• To address the relationship between
  problem-solving techniques and strategies for
  effectively solving real-world problems
• Finally, to consider the impact of
  interdisciplinary factors on software
  development, including the critical role of
  people and financial factors.

7
Basic Planning Control

• Introduction
• Characteristics of SW Development Strategies
• Life-Cycle Models
• The Waterfall Model
• Incremental Iterative Models
• Risk-Reduction Models
• The Prototyping Model
• The Spiral Model
• The Cleanroom Model

8
Basic Planning Control Introduction

• SW engineering as a cognitive reaction to the
  complexities of SW development
• Comparison to making a journey
• A wide array of strategies for organizing the
  process of SW development has emerged over the
  past 40 yrs
• Represent pre-tested patterns for successful
  development under different conditions
• Share similar objectives, but reach their goals
  by different routes
• Known as software development life-cycle models
  or process models
• Encompass the entire SW development process from
  cradle to grave
• SW process model vs. method or technique

9
Basic Planning Control Introduction

• The authors proposition
• The historical evolution of SW process models has
  played a significant role in how models have
  diversified over time, with later approaches
  building on earlier ones and technological
  advances enabling new approaches
• These models share (in degrees) common
  characteristics
• These characteristics reflect universal human,
  technical and economic constraints under which
  development operates

10
Basic Planning Control Characteristics of SW
Development Strategies

• Common Characteristics of SW Development
  Strategies
• Emphasis on the role of requirements engineering
• Use of a multistage decomposition approach
  derived from the Waterfall Model
• Documentation requirements
• Stakeholder Involvement
• Objectives related to economic or business
  constraints
• Project Management
• Implicit or explicit adoption or embedding of
  recognized best practices

11
1. Emphasis On The Role Of Requirements
Engineering

• All the models (aside from the code-and-fix
  approach)
• Are problem solving approaches that apply
  requirements engineering to help solve problems
  based on problem specifications
• Need a well-defined problem definition as an
  input to the SW development process
• Problem-definition
• Underlies the need to use requirements
  engineering in process models
• Distinguished the pre-software-engineering era in
  which code-and-fix approaches prevailed.
• Increasing emphasis was put on clear problem
  definition combined with increasing user
  involvement
• Problems were recognized as user problems
  regardless of whether the user is internal or
  external the organizations

12
Use Of A Multistage Decomposition Approach
Derived From The Waterfall Model

• In response to needing to produce a
  well-engineered solution, the models implicitly
  or explicitly adopt some variation of the
  four-stage Waterfall Model, partitioning SW
  development into phases such as
• Analysis
• Design
• Coding
• Maintenance
• The relationships between the tasks vary
  substantially, however, with tasks sequential in
  some models, iterative in others, functionally
  independent or related by static or dynamic
  transformations

13
3. Documentation Requirements

• The models typically rely on documentation and
  conceptual artifacts such as diagrams as tools
  for planning development, monitoring its progress
  and assuring its quality
• Artifacts also provide a degree of traceability
  for the entire development process, a
  precondition for system testing, modification,
  maintenance and process improvement

14
4. Stakeholder Involvement

• The use of requirements necessitates user or
  stakeholder involvement to ensure that the SW
  product is a valid solution to the underlying
  problem
• Stakeholder Involvement represents the people
  dimension of the process, which affects every
  process phase, regardless of the degree of
  automation, because people are never absent from
  the process
• Stakeholders range from users of the SW product
  under development to individuals who decide on
  the systems requirements to system developers

15
5. Objectives Related To Economic Or Business
Constraints

• Problems arise out of the business or
  organization contexts , in which the primary
  concern is to produce a profitable SW solution
  that satisfies customer needs in a cost-effective
  manner and with appropriate quality.
• An efficient SW solution adds economic value to
  the organization
• The economic success of an application is
  measured in terms of metrics such a profit
  maximization, cost reduction or customer
  satisfaction
• The economic goals are reflected or represented
  in SW process models in terms of project
  deadlines, budge constraints and efficient use of
  resources

16
6. Project Management

• Project management is required
• In order to manage the complexity of the
  development process efficiently
• For the efficient utilization of resources
• Again underscores economic objectives

17
7. Best Practices

• The recognition or discovery over time of a
  variety of principles or best practices for SW
  Development. is a phenomenon that has affected
  the definition of SW models
• These practices have subsequently become embedded
  in development models

18
7. Best Practices, cont.

• Examples of some Best Practices
• Separation of concerns the most basic of the
  best practices principles recommends
  intellectually segregating from one another the
  consideration of different problem-solving issues
• This principle is reflected in the separate
  stages of the life cycle model
• Deferring decisions wherever possible to keep the
  development options flexible, is also reflected
  in the life-cycle stages
• Concentrating on the Goals of the Stakeholders
  rather than prematurely examining functional
  mechanism for achieving those objectives
• The utilization of Use Cases during
  requirements analysis, dependent on the
  identification of stakeholders goals

19
Basic Planning Control Characteristics of SW
Development Strategies

• Variation Among Models
• The most important source of variation among the
  SW processing is the variation within their
  shared characteristics
• Process models also exhibit, however, a number of
  difference rooted in factors such as
• The enabling technology underlying the model
• The nature of the problems addressed or the
  problem-solving approach adopted
• Interdisciplinary considerations
• The authors identify 8 important sources of
  variation in total as depicted in the following
  model

20
Variation Model

• Common Process Model
• Elements
• Requirements Engineering
• Multistage Decomposition
• Documentation Requirements
• Stakeholder Involvement
• Business Constraints
• Project Management
• Best Practices

21
Variations Factors

• Time refers to the historical evolution of
  models. As ideas about how to define modes has
  evolved, later models have built on earlier ones.
• Interdisciplinary contributions have led to the
  inclusion of managerial, financial and
  psychological factors in models
• What people believe to be the critical
  considerations in managing development affect
  process models
• Some models focus on tasks and task decomposition
  as the essential element in solving problems
• Some identify people as the essential element and
  have taken a people-centered approach to project
  management
• Risk management is the critical factor motivating
  the spiral

Time
Interdisciplinary Contributions
Critical Factors
22
Variation Factors, cont.

• The problem-solving approach or methodology
  adopted by a developer affects how the problem
  is modeled
• some based on structure design and others on
  object-oriented design
• some linear and other iterative
• some used sequential workflows and other
  concurrent workflows
• Behavior and Social considerations are the
  primary motivation for incorporating a system
  dynamics view of SW development process
• Past models being more static in nature
• Technological advances enable new approaches
• some models have been based on the enabling
  technology as the critical factor

Technology
Behavioral Considerations
Methodology
23
Variation Factors, cont.

• Modeling approaches can vary with the problem
  domain as well as problem size, structure and
  complexity
• some models have been tailored to specific
  problem domains and others have been kept generic
• some were developed with large systems in mind,
  with others for smaller projects
• problem structure varies according to its
  relations to the organizational hierarchy
• structured problems arise at the operational
  level
• semi-structured at the middle-management level
• unstructured at the upper-mgmt or strategic level
• problem complexity relates to problem structure
  and size and SW related organization effects,
  such as the recognized relation between
  organizational complexity and the impact of
  technical change, affect problem complexity and
  model design

Problem Domain
Problem Nature
24
Conclusion of SW Characteristics

• Within this two-fold framework of both common and
  varied elements, the authors proceed through the
  next several sections with a general overview and
  critic of existing SW development strategies.
• This overview serves to lay the foundation for
  their suggestions for future advancement in the
  field of SW Engineering.

25
Basic Planning and Control The Life-Cycle
Models

• The Waterfall Model 
• One of the first and most influential process
  models
• Introduced in the 1970s an historical influence
  in the evolution of subsequent models and basis
  for most SW acquisition standards
• Achievements
• Introduction of bidirectional feedback elements
  in the development process
• Addressed the general problem of the
  code-and-fix approach, which through time
  became poorly structured and difficult to
  maintain.
• Introduced prototyping
• Introduced the partitioning of problems into
  manageable pieces
• Different phases of the model incorporated the
  critical best practices of separation of
  concerns, localizing a given class of problems
  issue to a particular phase of the life cycle
• Each phase produced a document as its product
• Was widely used because it formalized certain
  elementary process control requirements
• it provided an explicit schedule that included
  quality control steps at each process completion

26
Basic Planning and Control The Life-Cycle
Models

• Shortcomings
• Often produced a poor match to the user
  requirements
• Feedback was local and confined to the successive
  stages to minimize the expensive rework
• Feedback was insufficient to capture the learning
  that results from user feedback and involvement
• Slow or unresponsive structure
• Did not provide a guide for activity
  transformation across phases, limiting its
  ability to handle changes arising during
  development
• Viewed the development. process as similar to a
  fixed, engineering-based, manufacturing process,
  rather than a dynamic, problemsolving process
  that could evolve over time as development
  experience was gained and learning occurred
• The document-driven standards encouraged
  developers to produce elaborate specifications of
  poorly understood user interfaces and
  design-support functions which in term produced
  large amts of unusable cod
• Lack of risk assessment
• Contractors and developers were forced to
  estimate costs based on limited information,
  putting either the developer or buyer at risk
  depending on the terms of the contract
• Risks included unstable budges and theft of
  intellectual property

27
Basic Planning and Control The Life-Cycle
Models
28
Basic Planning and Control The Life-Cycle
Models

• Incremental Iterative Models
• Also called phased development models
• Share common objective of reducing the cycle time
  for development
• Terms tend to be used interchangeably, but
  distinctions exist
• Iteration includes a repeated series of attacks
  on a problem
• Each attack or iteration is like a miniature
  development life cycle
• Tends to mean developing a prototype of the
  entire product in the first phase and repeatedly
  improving the product in subsequent phases o
  successive refinement until an effective system
  is created
• Incremental development also includes a series of
  iterations, but the successive iterations are
  understood as adding incremental functionality to
  the product
• Tends to be viewed as building a part of the
  intended system in each of a sequence of partial
  releases until the entire system is completed.

29
Basic Planning and Control The Life-Cycle
Models

• Incremental or Evolutionary Model
• The Evolutionary Development model, an example of
  the incremental model, was a reaction to the
  difficulties with WF model (Graham, 1992)
• Increments of system capability are released with
  subsequent stages of development based on user
  and developer experience with earlier releases
• The initial release of the system must provide
  sufficient capability to serve as a basis for
  user exercise and evaluation
• Each step constitutes a mini-life cycle, complete
  with its own functional product, manual,
  requirement specifications, review reports, etc.
• Each incremental step must include not only
  implementation, but also testing, documentation
  and training
• Various strategies are possible for deciding
  which increments to develop in which order
• Critical task can be implemented first to reduce
  development risk
• One may develop interface components to allow
  testing or important functional features to
  support incremental delivery

30
Basic Planning and Control The Life-Cycle
Models

• Benefits
• Promotes user acceptance, a concern that is
  typically one of the key problems in the
  successful adoption of new systems
• It brings the new system into an organization
  inch by inch decreasing organizational
  disruption and allowing users to gain familiarity
  with the use and benefits of the system
  gradually, with requiring steep learning curve
• Reflects the recognition that it is often only at
  the end of development that one clearly realizes
  how the project should have been defined,
  designed and implemented in the first place
• Drawbacks
• Initial release may be so far off target that
  users fail to use it and may lose confidence in
  the entire process
• Potentially creates an inflexible-point-solution
  with the result that the initially prescribed
  architecture may not scale to the entire system

31
Basic Planning and Control The Life-Cycle
Models

• Iterative Enhancement Model (Basili Turner,
  1975)
• Basili Turner defined iterative enhancement as
  a practical way to achieve step-wise refinement
• Develops the system through a series of
  subsystems the emerging system would be
  understood more thoroughly as the process
  proceeded, as what happens in the learning
  process
• The learning process can be used to improve the
  design as the system is iteratively extend
  through a sequence of partial systems, ultimately
  converging to the complete solution

32
Basic Planning and Control The Life-Cycle
Models

• Advantages
• Improved development team morale
• Early solution of implementation problems
• Reduced risk f the disasters that occur because a
  system cannot be developed as proposed or because
  of late integration of components
• Improved maintenance
• Improved control of over-engineering or
  gold-platting
• Measurement of productivity
• Estimation feedback
• Smoother staffing requirements
• Difficulties
• Hardware-related problems
• Life-cycle problems
• Management problems
• Financial and control problems
• User-developer relationship problems

33
Basic Planning and Control The Life-Cycle
Models
34
Basic Planning and Control Risk Reduction
Models

• Risk in context of Software Development
• The state or property of a development project
  that, if ignored or left unresolved, will
  increase the likelihood of project failure
  (Roppenen Lyytinin, 2000)
• Potential loss times the probability of the loss
  (Boehm, 1991)
• The introduction of risk-driving models was a
  major advance of the existing document driven or
  code-driving models
• Most software development. incurs risk of failure
  due to large or novel systems or inadequate
  resources
• Risk is information dependent because the more
  certain information is available about a project
  and its global context, the lower the expectation
  of risk will be
• Addressing risk in SW development was an
  important driving factor in the evolution of the
  process models

35
Basic Planning and Control Risk Reduction
Models

• The Prototyping Model
• In the context of SW or Info Systems, three
  characteristics of prototyping include
• Being a temporary system
• Being designed rapidly
• Providing a tangible or visual expression of a
  proposed system
• Prototyping has been used in almost every process
  model since the Waterfall Model
• Involves building a small version of the intended
  system allowing developers to work out the kinks
  in the specification and design of the system
  before its full-scale development
• Expectation of significantly reducing the risk of
  development
• The need for risk reduction derives from the
  novelty of the application or because the user
  interface design requires user experience and
  feedback based on the users live interaction
  with a tangible approximation of the desired
  product

36
Basic Planning and Control Risk Reduction
Models

• Prototypes can be coded in any language, but some
  special, high-level languages are particularly
  relevant
• Proposed purposes for prototyping in process
  models include
• Used as a generic tool in the development process
• Serving as the basis of a complete process model
  using a comprehensive prototyping model beginning
  with system requirements and ending with a
  complete delivery system with iterative revisions
  implemented during the process (not all agree
  that this is a viable use)
• Used as a helpful tool in specific model phases
  like requirements or in assessing the feasibility
  of the entire development
• As a tool in the cases when developers are
  dealing with undecided users and clarifying fuzzy
  requirements

37
Basic Planning and Control Risk Reduction
Models

• Types of Software Prototyping
• Rapid Prototyping
• Throwaway or Quick And Dirty Prototyping
• Incorporated Prototyping
• Experimental Prototyping
• Evolutionary Prototyping
• Embedded Prototyping
• Vertical Prototyping
• Low-fidelity And High-fidelity Prototyping
• Presentation Prototypes
• Mockups
• Pilot Systems

38
Basic Planning and Control Risk Reduction
Models

• Benefits of prototyping
• Gain important feedback from users early in the
  development process
• Provide a common baseline for users and
  developers to identify problems and opportunities
• Motivate user involvement
• Help prevent misunderstanding btw users and
  developers
• Strengthen working relationships between users
  and developers

39
Basic Planning and Control Risk Reduction
Models

• Shortcomings
• May lead to user overestimation of the
  capabilities of the SW product
• Difficulties in program management and control
• Arise partly from difference between the
  prototyping approach and the more well-defined
  life cycle approaches
• System specifications evolve over the course of
  the project
• Users are more involved, and changes more
  frequent
• Difficulty in applying the technique to large
  system design
• Potential difficulties in maintaining necessary
  user interest
• if high priority user requirements are met in
  prototype, users interest may actually decline

40
Basic Planning and Control Risk Reduction
Models
41
Basic Planning and Control Risk Reduction
Models

• The Spiral Model
• Boehms risk-focused Spiral Model consists of s
  series of Waterfalllike cycles, with each cycle
  addressing the development of the software
  product at a further level of elaboration
• It is usually depicted as an expanding spiral
  curve in contrast to the linear diagram of the
  classic Waterfall model
• The spiral symbolizes the idea that the model
  repeatedly circles back again to a go or no-go
  decision on the project, based on a repeatedly
  revised understanding of the risk of the
  development
• Each cycle consists of four phases analysis
  design code and test, like the Waterfall model
• In each successive cycle, the developer
  identifies the objectives of the portion of the
  product being elaborated and then reevaluates the
  alternatives with respect to the projects
  objectives and constraints

42
Basic Planning and Control Risk Reduction
Models

• The spiral model relies heavily on prototyping
  and on concepts from software engineering
  economics to understand and minimize development
  risk
• It is effective in evaluating and verifying
  quality and performance as development proceeds
• It is flexible an designed for customization
• It allows the incorporation of other process
  models in an inclusive framework driven by
  project requirements and the dual objective of
  maximizing user satisfaction with minimizing
  development uncertainty
• Alternative development models can be used as
  tools on an as-need bases rather than being
  adopted in their entirety
• The structure enforces close attention to user
  satisfaction and approval as it iterates through
  the succession of cycles of validation and
  verification

43
Basic Planning and Control Risk Reduction
Models

• The Spiral Model was extended into the Win-Win
  Spiral model, to better prepare for the systems
  next level objectives, constraints and
  alternatives
• It entails identifying the stakeholders of the
  system, to determine their win conditions, and to
  negotiate an agreed upon set of
  objectives-constraints and alternatives for each
  spiral stage
• The modified approach filled a critical gap in
  the original model by providing a means for
  resolving questions such as Where do the
  next-level objectives and constraints come from?
  and How do you know theyre the right ones?
• The win-win approach is used to determined 3
  critical project milestones and to anchor the
  development process
• (1) life-cycle objectives (LCO)
• (2) life-cycle architecture (LCA)
• (3) initial operational capability (IOC)
• These milestones also set a reference point for
  critical management decisions

44
Basic Planning and Control Risk Reduction
Models
45
Basic Planning and Control Risk Reduction
Models

• Cleanroom Model
• Developed by IBM in the 1980s
• Uses a team-oriented model that focuses on
  enforcing the use of theoretically sound
  engineering processes and practices
• Based on the three foundations of
• Incremental development under statistical quality
  control
• Mathematical principles
• Testing based on statistical principles
• Its quality control driven philosophy is intended
  to improve the manageability and predictability
  of the development process
• Its formal mathematical and correctness
  techniques are intended to ensure its validity
• It puts a premium on defect prevention, and
  eliminating costly error removal process
• It develops SW under statistical guaranteed
  levels of quality control to produce a
  certifiably reliable product that exhibits zero
  failures in the field

46
Basic Planning and Control Risk Reduction
Models
47
Tools, Objects Reuse

• Case Tools
• Object-Oriented Reuse Models
• Object-Oriented Models
• Rational Unified Process Model (RUP)
• Commercial Off-the-Self Model (COTS)
• The Re-engineering Model

48
Case Tools

• CAD (Computer Aided Design) tools are used in
  fields such as mechanical and computer
  engineering or architecture to automate many
  parts of the design processes
• These tools automate routine tasks, check for
  consistencies, provide templates for design etc.
• The analogous tools in SW development are CASE
  Tools (Computer Aided SW Engineering)
• Case tools can assist developers throughout the
  life-cycle, although they are more beneficial at
  some stages than at others
• upper CASE tools or front-end tools tools used
  in the early phases of the life cycle (analysis
  or req., specifications, and design) are called
• lower CASE tolls or back-end tools those used
  during implementation and maintenance
• CASE tools are currently available for every
  stage of the development cycle

49
Case Tools, cont.

• CASE tools can not only speed up the development
  process, but they also can provide machine
  readable representations for process information
  that can then be shared with other tools
• Up until now, the formal languages that underpin
  the CASE tool environment did not model the
  semantics of a design as they did in
  engineering CAD tools but important steps have
  been introduced to move it in this direction
• UML (Universal Modeling Language) uses class
  diagrams to describe the relations btw the
  objects or classes in a problem
• UML also utilizes use cases that represent
  functional test cases of an important sequence
  of operations intended to clarify what is
  happening at the requirements level rather than
  at the code testing level

50
Case Tools, cont.

• Technology-enabled models include those based on
  automation using CASE Tools
• Although traditional environments have been
  supported by loosely coupled CASE tools that
  independently assisted in each phase of the life
  cycle, more sophisticated architectures have been
  introduced which provide mechanisms for ensuring
  that tools are properly used and that the user
  interface can support the monitoring of team
  members actions as well as the coordination
  their activities in an integrated manner
• Their architecture uses a rule-based AI
  (artificial intelligence) approach
• The TAME process modeling approach represents an
  advance in integrating process modeling with
  product metrics and computer supported
  capabilities of CASE tools in a comprehensive
  framework

51
Case Tools, cont.
52
Object-Oriented Reuse Models

• The motivation underlying the use of objects is
  that they represent a natural way to model
  phenomena and correspond to the most fundamental
  of cognitive elements the concept
• The conceptual nature of objects also underlies
  their ability to be designed for reuse
• Reuse as an idea is important because it reduces
  risk and development costs

53
Object-Oriented Reuse Models

• The concept of the reuse of patterns for
  solutions to problems represented an advance in
  facilitating and standardizing the architectural
  or system design phase of SW development
• Patterns for problem solutions frequently repeat
  themselves
• Design patterns represent abstractions or generic
  types of proven, successful, standard SW
  architectures for solving regularly recurring
  problem types
• The Gang of Four compiled over 20 standard
  design patters for SW applications to keep
  developers from reinventing the wheel
• Patterns also serve as a standardized way of
  communicating among developers, enabling them to
  convey the nature of their solutions accurately
  and succinctly to others

54
Object-Oriented Models
55
Rational Unified Process Model (RUP)

• UML has become an accepted standard notation for
  OO architecture and design
• This acceptance allows developers to perform
  system design and provide design documentation in
  a consistent and familiar manner
• It reduces the need fro developers to learn new
  notational techniques and improves communication
  among teams and stakeholders
• The Rational Rose SW suite is GUI or visual
  modeling tool available from Rational SW that
  lets developers model a problem, its design,
  implementation, and the entire development
  process, all the way through testing and
  configuration management using UML notation

56
Rational Unified Process Model (RUP)

• RUP is built around what its designers believed
  are the essential best practices for effective
  SW development
• Iterative development the spiral approach is
  intended to mitigate development. risks by using
  a combination of early implementation and
  requirements testing and modification in order to
  expose requirements early on
• Requirements Mgmt the mgmt requirements
  objective specifically addresses evaluation and
  tracking the effect of changes to requirements
• Use of Component-based SW architecture
  component-based development allows the use (or
  reuse) of commercially available system
  components and ultimately continuous
  (re)development but involves the complexities of
  bluing the components together
• It is consistent with the concept of Separation
  of Concerns
• Makes use of tools that support visual design of
  the system, continuous verification and change
  management

57
Commercial Off-the Shelf Model (COTS)

• COTS is a component-based approach to development
  which makes use of commercial off the shelf
  (COTS) products and is a good example of how OO
  methodologies have affected development
  strategies
• COTS development reflects an expanded concept of
  reuse in which proposed systems are configured
  out of pre-built components or subsystems
• The term COTS typically refers to a SW product
  supplied by a vendor that has a specific
  functionality
• The packages used in COTS development permit the
  rapid configuration of composite systems
• The paradigm requires developers to understand
  the characteristics, incompatibilities and
  performance quality of those preexisting products

58
Commercial Off-the Shelf Model (COTS)

• Integrating the COTS approach into the different
  phases of the process life-cycle model creates a
  new kind of development framework however, the
  Spiral Model provides a good skeletal
  architecture for the approach
• Levels of COTS usage
• turnkey level a single COTS product is used and
  left unaltered
• intermediate level a single COTS product is
  integrated with other system components
• multiple peer level COTS products integrated
  into a single system
• The role of a SW developer in a COTS development
  project is one of identifying and acquiring
  appropriate prepackaged SW components and
  assembling those components to build or
  synthesize the desired system

59
Commercial Off-the Shelf Model (COTS)
60
The Reengineering Model

• The Reengineering Process Model originally
  emerged in a business or organization context as
  a response to the customary business metric of
  time, cost and risk reduction
• Reengineering is especially attractive in
  situations in which significant advances in
  existing technologies have been made that may
  enable breakthroughs in the performance or
  functionality of an existing system
• Although reengineering has influence the SW
  process modeling literature and some
  reengineering models have been introduced it has
  been an overlooked approach
• 3 main phases in SW reengineering (Somerville,
  2000)
• Defining the existing system
• Understanding and transformation
• Reengineering the system

61
The Reengineering Model

• The process entails taking legacy systems and
  reimplementing them to make them more
  maintainable
• As a part of this reengineering process, the
  system may be redocumented or restructure or even
  retranslated to a more modern programming
  language
• The system may be implemented on a different
  architectural platform and data may be migrated
  to a different database management system
• Reengineered components can be constructed
  through the application of an externally provided
  reengineering service, through reengineering
  tools, or through COTS SW if there is a fit btw
  the available COTS SW and the reengineered need

62
The Reengineering Model

• Reasons for reengineering an exiting system
• Expediting the transition of legacy SW to
  changing organizational requirements or standards
• Converting an existing system to newer SW
  technologies or paradigms (such as object
  oriented) platforms
• Improving the maintainability of the SW
• Reduction in the cost of maintenance
• Reasons for reengineering rather than
  redeveloping
• Legacy systems embody critical corporate
  knowledge and it may be difficult or impossible
  to understand adequately the rationale underlying
  the original system
• Sunk cost represented by the legacy developments
  is a critical factor
• The cost of developing reengineered code is
  recognized to be significantly less than for
  newly developed code
• It is also more effective in terms of return on
  investment than other alternatives

63
The Reengineering Model

• SW reengineering should not be confused with
  Business Process Reengineering (BPR) which is
  derived from business mgmt literature.
• SW reengineering refers to the reengineering of
  components of an existing SW system
• Business process reengineering refers to the
  fundamental rethinking and radical redesign of
  business processes to achieve dramatic
  improvements in critical, contemporary measures
  of performance, such as cost, quality, service
  and speed
• There exists, however, a causative relation
  between the two concepts because the need or
  desire to reengineer a business process may
  likely require a redesign of that businesss
  software systems

64
The Reengineering Model
65
Process Improvement

• Productivity-Driven Dynamic Process Methodology
• Human Factors in Development Models
• The Capability Maturity Model
• Personal and Team SW Development Models

66
Productivity-Driven Dynamic Process Methodology

• The simulated approach to process modeling
  represents an attempt to understand the impact of
  project management and economic effects on SW
  development by using simulation
• It examines the effects of management and process
  structure on team effectiveness by using a
  computer model for SW project management based on
  systems dynamics methodology
• A computer model allows one to address certain
  concerns in an automated scenario-like manner
• The model applies Steiners theory of group
  productivity, which computes actual productively
  as potential productivity minus process defects
• Simulation models factors such as human resource
  management, scheduling pressure, project control,
  etc.

67
Productivity-Driven Dynamic Process Methodology

• According to the Steiner theory, faulty processes
  are a key element in explaining way group
  problem-solving processes fall short of their
  potential
• Faulty process that may detract from the
  potential productivity of system include dynamic
  motivation factors and communication overhead
• dynamic motivation factors include things such as
  the impact of schedule pressures on work and the
  effect of budget slack (excess)
• The communications overhead is related to the
  requirements of intra-team communications
• An advantage of the system dynamics model is that
  it permits computerized, simulated controlled
  experiments to test the impact of different
  development strategies

68
Human Factors in Development Models

• The role of human factors in development process
  models deserve greater attention because
  technological considerations alone do not provide
  a comprehensive model for SW processes
• Human factors enter the picture in many ways and
  some SW process models address the impact of
  personal competence and behavior on SW
  development
• Other models, such as the CMM, closely and
  formally addresses the team and organizational
  context in which a development process is
  embedded
• No comprehensive models, however, systemically
  address the development process from the
  viewpoint of the human actors engaged in and
  implementing the process and its artifacts
• The authors hope that this book addresses these
  issues, at least partially, by broadly
  considering the impact of cognitive
  problem-solving factors, stakeholder roles and
  concerns, the organization context and
  marketplace forces on the development process

69
Human Factors in Development Models

• Human-centered issues that affect the SW process
• Cognitive phenomena affect how individuals (team
  and stakeholders) think about a problem and its
  solution
• A cognitive perspective on development would
  address how the people involved perceive,
  understand, and solve problems
• At the group level, social and psychological
  factors affect group behaviors, such as how
  developers interact with one another as
  individuals or as a team
• Group cognition also affects the collective
  analysis of problems and group communication

70
Human Factors in Development Models

• Human-centered issues, cont.
• Visualization plays key role in defining and
  understanding the artifacts produced during
  development
• The forms of mental models for logical systems is
  not clearly understood
• From a behavioral and cognitive view, the
  software tools that designers use should be
  designed to be compatible with how designer and
  developers actually behave, as opposed to
  managerial templates for how the process is
  supposed to work
• The demands of domain knowledge strongly affect
  developers, who may require considerable learning
  time and effort to become adequately familiar
  with the application domain
• The customer is similarly subject to the same
  learning requirements, which also slow down the
  process through specification changes
• Collaboration among the designers entails
  extensive communication to ensure design issues
  are understood in a consistent manner by
  different individual tools that support this
  communication and coordination are at least as
  essential as tools that support transformation of
  artifacts.

71
The Capability Maturity Model

• The Capability Maturity Model develop by the SEI
  is a model for identifying the organizational
  processes required to ensure SW process quality
• It is based on a set of quality assurance
  standards originally develop by the ISO under the
  designation of ISO9000 in 87 and then revised in
  94 and 00.
• The purpose of these standards is to define the
  quality system that a business or industrial
  organization would need to follow to ensure the
  consistency and quality of its products

72
The Capability Maturity Model

• The CMM is a multistage, process definition model
  intended to characterize and guide the
  engineering excellence or maturity of an
  organizations SW development processes.
• The model prescribes practices for planning,
  engineering, and managing SW development and
  maintenance and addresses the usual goals of
  organizational system engineering processes
  quality improvement, risk reduction, cost
  reduction, predictable process, and statistical
  quality control
• The model is a program for how to develop SW in a
  professional, engineering-based manner it
  prescribes an evolution improvement path from an
  ad hoc, immature process to a mature, discipline
  process

73
The Capability Maturity Model

• The CMM identifies 5 levels of SW development
  maturity in an organization
• level 1(Initial) SW development follows no
  formal development process
• level 2 (Repeatable)SW mgmt controls have been
  introduced and some SW process is followed
• level 3 (Defined) development process is
  standard and consistent.
• level 4 (Managed) qualitative and quantitative
  measures or organizational processes have been
  put into place
• level 5 (Optimizing) mechanism designed to
  ensure continuous process improvement and
  optimization have been established

74
The Capability Maturity Model

• The higher the CMM maturity level is, the more
  discipline, stable and well-defined the
  development process is expected to be and the
  environment is assumed to make more use of
  automated tools an the experience gained from
  many past successes
• Each advance reflects a further degree of
  stabilization of an organizations development
  process with each level institutionalizing a
  different aspect of the process

75
The Capability Maturity Model
76
Personal and Team SW Development Models

• The Personal SW Process model (PSP) was developed
  by Watts Humphry (95, 97) of the SEI to guide
  individual developers in their disciplined
  approach to SW development
• The PSP model uses a stage-wise approach (like
  the CMM) aimed at gradually improving individual
  behavior by processing through a multilevel set
  of standards
• The PSP model was developed to support the CMM
  because the latter depends on the competence and
  professionalism of the practitioners to be
  effective.
• The PSP approach represents a continuation of the
  quality assurance work

77
Personal and Team SW Development Models

• The idea of PSP is to allow SW engineers to plan
  and track the quality of their work so that they
  can produce better quality products
• It requires developers to plan their work before
  hand, monitor their time and effort and log the
  errors that they make
• An essential benefit of the process is the
  relatively prompt feedback that the developers
  get from the data that they collect on their
  performance.

78
Personal and Team SW Development Models

• Defect monitoring removal are key elements in
  the process a central belief is that effect
  managements a SW engineers personal
  responsibility.
• People learn to keep track of the phases in which
  defects were introduced and removed how long it
  took to fix them and descriptions of the type of
  defect
• The clerical form-filling demands imposed by the
  PSP requirements for developers to monitor their
  work in order to create benchmarks for gauging
  improvement have met with criticism
• Despite these concerns, it is concluded that the
  PSP model more than compensates for the extra
  overhead incurred in terms of improvements in
  deign quality, defect removal and the ability to
  estimate project size and time
• The availability of automated application to
  support the data gathering, also help to mitigate
  the clerical demands

79
Personal and Team SW Development Models

• The development of human resources is
  increasingly recognized as an essential element
  in improving the outcomes of SW development
  processes
• The Japanese version of continuous process
  improvement, Kaizen, uses a strategy for quality
  enhancement based on viewing HR as an
  organizations most important asset
• Also recognized is the idea of designing HR
  Management Systems (HRMS) that systematically
  enhance the performance of teams

80
Personal and Team SW Development Models
81
Software Development Strategies Reinventing How
It is Done

• Open Source Model
• Agile Software Development
• RAD
• Workflow Application Models
• Aspect Oriented Development

82
Open Source Model

• Best used when
• Faster development is needed
• Experienced developers are available
• Open standards
• Disadvantages
• Must redistribute (Gnu General Public License)
• Quality depends on source code
• Source code may not be specific to you exact use
• Examples
• Shareware
• Freeware

83
Agile Software Development

• Driven by ongoing relationships with customers
• Dominated by twin objective
• Minimize time for decision making
• Minimize time to transfer information
• Does not follow frozen contractual plans
• Scope Creep?

84
Rapid Application Development

• Heavy interaction with customer
• Frequent version releases
• Typically used for smaller stand alone systems
• Negative aspect is the tendency to focus on speed
  of development over the quality of a long term
  product
• Use for support product?

85
Workflow Application Models

• Functions are important, but so is the whole
  process
• Ad Hoc vs Collaborative Workflows
• Low vs High value
• Administrative Workflows
• Low business value
• Production Workflows
• High business value, critical core.

86
Aspect Oriented Development

• Use object oriented development as a base
• Aspect Oriented then adds a layer of
  cross-cutting properties
• Envision an object that exhibits behavior but
  also requires synchronization and scheduling

87
An Assessment of the Process Life-Cycle Models

• TIME!!!!!!
• Is There a Need
• Classic Invalid Assumptions
• New Business Model
• Role of Problem-Solving Process
• Redefining the Process

88
The Dimension of Time

• Is time a critical factor?
• Time to market (long term aspect)

89
Is There a Need for a Business Model in Software
Engineering?

• Theory
• Comprehensive goals
• Broad perspectives
• High premium on quality
• Catch all solutions

• Reality
• Limited tools
• Narrowly focused practitioners
• Insufficient inputs to the problem solving
  process
• Inability to marry both software and hardware
  needs

90
Classic Invalid Assumptions

• Software problems are primarily driven by
  internal sofware factors
• Sofware development process is independent of
  the business processes in organizations
• Software project was separate from the software
  process
• Two broad approaches in sofware engineering one
  is process centered and the other is architecture
  centered
• Direct quotes taken from Strategic Software
  Engineering An Interdisciplinary Approach (2005)

91
New Business Model

• Solutions are not just software, but everything
  needed to solve the problem
• Problems will be defined through an
  interdisciplinary perspective
• Development process will be combined with the
  business process

92
Role of Problem-Solving Process

• Data
• Important for raw facts
• Can sometime be insufficient or overwhelming
• Problem Definition
• Involves structuring, analyzing, and interpreting
  the data for definition
• Tools and Capabilities
• Tools and capabilities help to support and
  accelerate the process

93
Redefining the Process

• Need to match process against business goals
• Need to address diverse environment and
  interdisciplinary factors.
• The reality is that most situations will not fit
  any specific model.

94
THANK YOU

• Questions?
• Comments?
• Concerns?