Title: Advanced Software Engineering Methods CSC 619'2 Vincent Ele Asor, PhD
1Advanced Software Engineering Methods CSC
619.2Vincent Ele Asor, PhD
- Contents
- Overview of Software Engineering Principles
- Application to concurrent programs distributed
software and fault tolerance - Analysis and Verification techniques
- Verification of concurrent locks
- Theory of a process
- Distributed System Kernels
- Interleave Principle
- Duality Principle
- Application of Verification Techniques to System
deadlocks and software fault-tolerance - Detailed Analysis of
- Distribution Locks
- Readers-and-Writer problems
- Message Passing system
- Data Flow design methodologies
- Use of Data flow techniques in Operating Systems
Software Engineering is A step-by-step approach
in analyzing, designing, implementing and
maintaining software involving the use of
engineering tools (called CASE).
Computer Aided Software Engineering (CASE, or
"assisted") A technique for using computers to
help with one or more phases of the software
life-cycle, including the systematic analysis,
design, implementation and maintenance of
software. Adopting the CASE approach to building
and maintaining systems involves software tools
and training for the developers who will use them.
2Definition
- Engineering is
- The art or science of making practical
application of the knowledge of pure sciences, as
physics or chemistry, as in the construction of
engines, bridges, buildings, mines, ships, and
chemical plants or more simply put, 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,
etc.
3Definition (Contd.)
- Software is
- a program used to direct the operation of a
computer, as well as documentation giving
instructions on how to use them.
4Definition (Contd.)
- Software Engineering is
- A step-by-step approach in analyzing, designing,
implementing and maintaining software involving
the use of engineering tools (called CASE).
5Definition (Contd.)
- Simplified definition of Software Engineering
- A systematic approach to the analysis, design,
implementation and maintenance of software. It
often involves the use of CASE tools. There are
various models of the software life-cycle, and
many methodologies for the different phases. - Software is a program used to direct the
operation of a computer, as well as documentation
giving instructions on how to use them. - Computer Aided Software Engineering (CASE, or
"assisted") A technique for using computers to
help with one or more phases of the software
life-cycle, including the systematic analysis,
design, implementation and maintenance of
software. Adopting the CASE approach to building
and maintaining systems involves software tools
and training for the developers who will use
them. - Methodology is a set or system of methods,
principles, and rules for regulating a given
discipline, as in the arts or sciences
6Definition (Contd.)
- Software Life-Cycle
- The phases a software product goes through
between when it is conceived and when it is no
longer available for use. The software life-cycle
typically includes the following requirements
analysis, design, construction, testing
(validation), installation, operation,
maintenance, and retirement. - The development process tends to run iteratively
through these phases rather than linearly
several models (spiral, waterfall etc.) have been
proposed to describe this process. - Other processes associated with a software
product are quality assurance, marketing, sales
and support.
7Evolution of Software Engineering
- The term is almost 40 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
8Software Engineering in Summary
- 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
9Challenges
- Few guiding scientific principles
- Few universally applicable methods
- As muchmanagerial / psychological /
sociologicalas technological
10Causes of these challenges
- 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
11Software 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
12Software 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
13Economic and Management Aspects of SE
- Software production development maintenance
(evolution) - Maintenance costs gt 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
14Relative Costs of Fixing Software Faults
200
30
10
4
3
2
1
Requirements
Specification
Planning
Design
Implementation
Integration
Maintenance
15Mythical Man-Monthby 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 - Brookss Law
- Adding personnel to a late project makes it later
16Software Development LifecycleWaterfall Model
Requirements
Design
Implementation
Integration
Validation
Deployment
17Software Development LifecycleSpiral Model
18Requirements
- 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
19Architecture/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
20Architecture vs. DesignPerry 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.
21Implementation 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
22Component-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
23Different Flavors of Components
- Third-party software pieces
- Plug-ins / add-ins
- Applets
- Frameworks
- Open Systems
- Distributed object infrastructures
- Compound documents
- Legacy systems
24Verification 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
25Deployment Evolution
- Operation ? Change
- maintain software during/after user operation
- determine whether the product still functions
correctly - Difficulties
- rigid design
- lack of documentation
- personnel turnover
26Configuration 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)
27CM in Action
1.0
28Software Engineering Principles
- Rigor and formality
- Separation of concerns
- Modularity and decomposition
- Abstraction
- Anticipation of change
- Generality
- Incrementality
- Scalability
- Compositionality
- Heterogeneity
29From Principles to Tools
30Software Qualities
- Qualities (a.k.a. ilities) are goals in the
practice of software engineering - External vs. Internal qualities
- Product vs. Process qualities
31External 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
32Product 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
33Some 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
34Some Software Qualities (cont.)
- Robustness
- reasonable behavior in unforeseen circumstances
- subjective
- a specified requirement is an issue of
correctnessan unspecified requirement is an
issue of robustness - Usability
- ability of end-users to easily use software
- extremely subjective
35Some 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
36Some 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
37Some 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.
38Some 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
39Some 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
40Software 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
41Assessing 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
42Software 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