Strategic Software Engineering - PowerPoint PPT Presentation

1 / 94
About This Presentation
Title:

Strategic Software Engineering

Description:

Strategic Software Engineering: An Interdisciplinary Approach. By Fadi P. Deek, ... Published in 2005 by Auerbach Publications. Our Objectives. Introduction ... – PowerPoint PPT presentation

Number of Views:149
Avg rating:3.0/5.0
Slides: 95
Provided by: elizabeth149
Category:

less

Transcript and Presenter's Notes

Title: 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?
Write a Comment
User Comments (0)
About PowerShow.com