Overview of Software Engineering Principles by pyz17071

VIEWS: 11 PAGES: 38

									   Overview of Software
   Engineering Principles

                CSCI 589:
Software Engineering for Embedded Systems

              August 25, 2003
Engineering
   Engineering is …
       The application of scientific principles and methods
       To the construction of useful structures & machines
   Examples
       Mechanical engineering
       Civil engineering
       Chemical engineering
       Electrical engineering
       Nuclear engineering
       Aeronautical engineering
Software Engineering
   The term is 35 years old: NATO Conferences
       Garmisch, Germany, October 7-11, 1968
       Rome, Italy, October 27-31, 1969
   The reality is finally beginning to arrive
       Computer science as the scientific basis
            Other scientific bases?
       Many aspects have been made systematic
            Methods/methodologies/techniques
            Languages
            Tools
            Processes
    Software Engineering in a
    Nutshell
   Development of software systems whose
    size/complexity warrants team(s) of engineers
        multi-person construction of multi-version software
         [Parnas 1987]
   Scope
        study of software process, development principles,
         techniques, and notations
   Goal
        production of quality software, delivered on time, within
         budget, satisfying customers’ requirements and users’ needs
Ever-Present Difficulties
   Few guiding scientific principles
   Few universally applicable methods
   As much
    managerial / psychological / sociological
    as technological
Why These Difficulties?
   SE is a unique brand of engineering
       Software is malleable
       Software construction is human-intensive
       Software is intangible
       Software problems are unprecedentedly complex
       Software directly depends upon the hardware
            It is at the top of the system engineering “food chain”
       Software solutions require unusual rigor
       Software has discontinuous operational nature
Software Engineering ≠
Software Programming
   Software programming
       Single developer
       “Toy” applications
       Short lifespan
       Single or few stakeholders
            Architect = Developer = Manager = Tester = Customer = User
       One-of-a-kind systems
       Built from scratch
       Minimal maintenance
Software Engineering ≠
Software Programming
   Software engineering
       Teams of developers with multiple roles
       Complex systems
       Indefinite lifespan
       Numerous stakeholders
            Architect ≠ Developer ≠ Manager ≠ Tester ≠ Customer ≠ User
       System families
       Reuse to amortize costs
       Maintenance accounts for over 60% of overall
        development costs
Economic and Management
Aspects of SE
   Software production =
       development + maintenance (evolution)
   Maintenance costs > 60% of all development
    costs
       20% corrective
       30% adaptive
       50% perfective
   Quicker development is not always preferable
       higher up-front costs may defray downstream costs
       poorly designed/implemented software is a critical
        cost factor
  Relative Costs of Fixing
  Software Faults
                                                                                   200




                                                                      30

                                                      10
                                3          4
    1              2
Requirements   Specification   Planning   Design   Implementation   Integration   Maintenance
Mythical Man-Month
by Fred Brooks
   Published in 1975, republished in 1995
       Experience managing development of OS/360 in 1964-65
   Central argument
       Large projects suffer management problems different in
        kind than small ones, due to division in labor
       Critical need is the preservation of the conceptual
        integrity of the product itself
   Central conclusions
       Conceptual integrity achieved through chief architect
       Implementation achieved through well-managed effort
   Brooks’s Law
       Adding personnel to a late project makes it later
   Software Development Lifecycle
   Waterfall Model
Requirements

          Design

               Implementation

                         Integration

                                  Validation

                                         Deployment
         Software Development Lifecycle
         Spiral Model
                            Evaluate alternatives,
Determine objectives        identify, resolve risks,
alternatives, constraints   develop prototypes




                            Develop, verify
  Plan next phases          next-level product
     Requirements
   Problem Definition → Requirements Specification
       determine exactly what the customer and user want
       develop a contract with the customer
       specifies what the software product is to do
   Difficulties
       client asks for wrong product
       client is computer/software illiterate
       specifications are ambiguous, inconsistent, incomplete
        Architecture/Design
   Requirements Specification → Architecture/Design
       architecture: decompose software into modules with
        interfaces
       design: develop module specifications (algorithms, data
        types)
       maintain a record of design decisions and traceability
       specifies how the software product is to do its tasks
   Difficulties
       miscommunication between module designers
       design may be inconsistent, incomplete, ambiguous
Architecture vs. Design
[Perry & Wolf 1992]
   Architecture is concerned with the selection of
    architectural elements, their interactions, and
    the constraints on those elements and their
    interactions necessary to provide a framework
    in which to satisfy the requirements and serve
    as a basis for the design.
   Design is concerned with the modularization
    and detailed interfaces of the design elements,
    their algorithms and procedures, and the data
    types needed to support the architecture and
    to satisfy the requirements.
    Implementation & Integration
   Design → Implementation
       implement modules; verify that they meet their
        specifications
       combine modules according to the design
       specifies how the software product does its tasks
   Difficulties
       module interaction errors
       order of integration may influence quality and
        productivity
Component-Based
Development
   Develop generally applicable components of a
    reasonable size and reuse them across
    systems
   Make sure they are adaptable to varying
    contexts
   Extend the idea beyond code to other
    development artifacts
   Question: what comes first?
       Integration, then deployment
       Deployment, then integration
Different Flavors of
Components
   Third-party software “pieces”
   Plug-ins / add-ins
   Applets
   Frameworks
   Open Systems
   Distributed object infrastructures
   Compound documents
   Legacy systems
Verification and Validation
   Analysis
       Static
       “Science”
       Formal verification
       Informal reviews and walkthroughs
   Testing
       Dynamic
       “Engineering”
       White box vs. black box
       Structural vs. behavioral
       Issues of test adequacy
Deployment & Evolution
   Operation → Change
       maintain software during/after user operation
       determine whether the product still functions
        correctly
   Difficulties
       rigid design
       lack of documentation
       personnel turnover
Configuration Management
(CM) [Tichy 1988]
   CM is a discipline whose goal is to
    control changes to large software
    through the functions of
       Component identification
       Change tracking
       Version selection and baselining
       Software manufacture
       Managing simultaneous updates (team
        work)
CM in Action
    1.0

     1.1

     1.2   2.0         4.0

     1.3   2.1

     1.4   2.2   3.0

     1.5         3.1
Software Engineering
Principles
   Rigor and formality
   Separation of concerns
       Modularity and decomposition
       Abstraction
   Anticipation of change
   Generality
   Incrementality
   Scalability
   Compositionality
   Heterogeneity
From Principles to Tools
             TOOLS



         METHODOLOGIES



          METHODS AND
          TECHNIQUES



           PRINCIPLES
Software Qualities
   Qualities (a.k.a. “ilities”) are goals in the
    practice of software engineering
   External vs. Internal qualities
   Product vs. Process qualities
External vs. Internal Qualities
   External qualities are visible to the user
       reliability, efficiency, usability
   Internal qualities are the concern of
    developers
       they help developers achieve external
        qualities
       verifiability, maintainability, extensibility,
        evolvability, adaptability
Product vs. Process Qualities
   Product qualities concern the developed
    artifacts
       maintainability, understandability,
        performance
   Process qualities deal with the
    development activity
       products are developed through process
       maintainability, productivity, timeliness
Some Software Qualities
   Correctness
       ideal quality
       established w.r.t. the requirements specification
       absolute
   Reliability
       statistical property
       probability that software will operate as expected
        over a given period of time
       relative
Some Software Qualities
(cont.)
   Robustness
       “reasonable” behavior in unforeseen
        circumstances
       subjective
       a specified requirement is an issue of correctness;
        an unspecified requirement is an issue of
        robustness
   Usability
       ability of end-users to easily use software
       extremely subjective
Some Software Qualities
(cont.)
   Understandability
       ability of developers to easily understand
        produced artifacts
       internal product quality
       subjective
   Verifiability
       ease of establishing desired properties
       performed by formal analysis or testing
       internal quality
Some Software Qualities
(cont.)
   Performance
       equated with efficiency
       assessable by measurement, analysis, and
        simulation
   Evolvability
       ability to add or modify functionality
       addresses adaptive and perfective maintenance
       problem: evolution of implementation is too easy
       evolution should start at requirements or design
Some Software Qualities
(cont.)
   Reusability
       ability to construct new software from existing
        pieces
       must be planned for
       occurs at all levels: from people to process, from
        requirements to code
   Interoperability
       ability of software (sub)systems to cooperate with
        others
       easily integratable into larger systems
       common techniques include APIs, plug-in
        protocols, etc.
Some Software Qualities
(cont.)
   Scalability
       ability of a software system to grow in size
        while maintaining its properties and
        qualities
       assumes maintainability and evolvability
       goal of component-based development
Some Software Qualities
(cont.)
   Heterogeneity
       ability to compose a system from pieces developed in
        multiple programming languages, on multiple platforms, by
        multiple developers, etc.
       necessitated by reuse
       goal of component-based development
   Portability
       ability to execute in new environments with minimal effort
       may be planned for by isolating environment-dependent
        components
       necessitated by the emergence of highly-distributed systems
        (e.g., the Internet)
       an aspect of heterogeneity
Software Process Qualities
   Process is reliable if it consistently leads to high-
    quality products
   Process is robust if it can accommodate
    unanticipated changes in tools and environments
   Process performance is productivity
   Process is evolvable if it can accommodate new
    management and organizational techniques
   Process is reusable if it can be applied across
    projects and organizations
Assessing Software Qualities
   Qualities must be measurable
   Measurement requires that qualities be
    precisely defined
   Improvement requires accurate
    measurement
   Currently most qualities are informally
    defined and are difficult to assess
Software Engineering
“Axioms”
   Adding developers to a project will likely result in
    further delays and accumulated costs
   Basic tension of software engineering
       better, cheaper, faster — pick any two!
       functionality, scalability, performance — pick any two!
   The longer a fault exists in software
       the more costly it is to detect and correct
       the less likely it is to be properly corrected
   Up to 70% of all faults detected in large-scale software
    projects are introduced in requirements and design
       detecting the causes of those faults early may reduce their
        resulting costs by a factor of 100 or more

								
To top