ch.11 software engineering a preview. ch.12 outline definitions of software engineering (se)...
TRANSCRIPT
Ch.1 1
Software Engineering
A Preview
Ch.1 2
Outline
• Definitions of software engineering (SE)
• Historical origins of SE• SE as part of systems engineering• SE consists of many activities in
addition to programming• SE and other disciplines
Software Engineering: A Preview
• A computer science field that is dealing w/– large & complex sw systems– buit by a team or team of engineers– multi-version systems– long life-cycle (changes -> fix detects,
enhance, adaptation to new environment etc.)
Ch.1 3
Ch.1 4
Definitions• SE is
– «the application of engineering to software»
– «application of a systematic, disciplined, quantifiable, approach to development, operation, and maintenance of sw» IEEE
– «multi-person construction of multi verison sw» Parnas
Ch.1 5
Meaning
• Programmer – writes a complete program– a personal activity
• Software engineer– writes a sw component to be combined
w/ components written by other SEs.– components –> reusable, modifiable– a team activity
Ch.1 6
Need
• Programming evolved by algorithms, data structures, and OO programming.– not helping build [better, larger]
software.– writes a complete program– a personal activity
• differential equation solving (small program)• OS developing (scaled-up)
Ch.1 7
Strategy
• Vital engineering strategy– define problem– use and develop tools and techs.
• Parameters are not clear for SE– no mathematical tools exist– relies on experience & debate
Ch.1 8
Role of SE in system design
• SS is a part of a larger systems• Software requirements to be balanced against
others
– eg. Telephone switching system• Computers• Telephone lines• HW (satellite, telephones)• a controller SW
– eg. Traffic monitoring system– eg. Hospital administration
Satisfy requirements of HW, SW, and special devices
Ch.1 9
Role of SE in system design
• Complex balancing require SE to participate in developing requirements for the whole system.
• SE is a part of systems engineering– compromise & trade-offs– SW offers flexibility, HW offers
performance (eg. Coin-operated coffee machine)
A shortened history
• Programming – place sequence of instructions to get
the computer do sth useful– interaction btw programmer & computer– problematic when developing large
systems
• Large SW systems are significanty different
Ch.1 10
Ch.1 11
A shortened history
• The field of software engineering was born in 1968 in response to chronic failures of large software projects to meet schedule and budget constraints – recognition of "the software crisis"
• Term became popular after NATO Conference in Garmisch Partenkirchen (Germany), 1968
Ch.1 12
History – problem defined
• Problems in constructing large systems – understanding of problem– too much communication time– people leaving the Project– changes are not easy to apply
Ch.1 13
History – solutions
• Offered solutions– better managemet techs– different team organization– better programming languages & tools– uniform coding conventions– mathematical approaches
• Conclusion: apply engineering to software
History
SW costs < HW costs (was)SW costs >> HW costs (now)
•SE deals w/ entire life-cycle– conception -> design -> development
-> maintenance -> deployment -> evolution
Ch.1 14
Ch.1 15
Role of software engineer
• Software Engineer – must be a good-programmer
• Programming skill not enough (programming-in-the-small)
– familiar w/ design– translate vague requirements– form precise specifications– build models to balance trade-offs– A good Communicator– Schedule work (own and others)
programming-in-the-large
Ch.1 16
The software lifecycle«In theory- theory and practice are the same. In practice, they never are.»
Waterfall model -> life-cycle model1. Requirements analysis & specification
– feasibility study (costs & benefits)– by customer, developer, or marketing
org.– should be in end-user terms– requires interaction w/ users
Ch.1 17
The software lifecycleWaterfall model -> life-cycle model2. System design & specification
– architectural (high-level) design– detailed design– what – how dichotomy
3. Coding & module testing– produce actual code for end-user
the problem(analysis)
to solve(design)
Ch.1 18
The software lifecycleWaterfall model -> life-cycle model4. Integration & system testing
– integrate components & test whole system
– might require testing code
5. Delivery & maintenance– deliver product (SW) to the customer– make sure it works well
Ch.1 19
The software lifecycle(a preview)
Requirements analysis and specification
Design and specification
Code and module testing
Integration and system testing
Delivery and maintenance
waterfall model
Concurrent engineering?•parallelism
Ch.1 20
Relationships betweenSE and other CS disciplinesThere is a synergistic relationship1. Programming languages SE -> PL
– modularity (Java packages)– Exception-handling (reliable SW)– UI (visual languages)PL -> SE– precise requirement (by machine processible PLs)– Forming a language of commands (UNIX Shell commands)– Formalization leads to automation (exploited for automatic SW generation)
Ch.1 21
Relationships betweenSE and other CS disciplines2. Operating systems
OS -> SE–initial large projects–virtual machines, levels of abstraction–separation of policy from mechanism fairness in task scheduling – time-slicing concurrency (what – policy) (how – mechanism)
SE -> OS–portable OSs–Protected and unprotected kernels (command line interpreter)
Ch.1 22
Relationships betweenSE and other CS disciplines3. Databases
DB -> SE–data independence notion (separation&specification)
• Use data w/o worrying about representation• DB offers concurrent Access to data (useful component)
SE -> DB–long transactions
• CVS (lock code, work on a small piece, forbid access)
Ch.1 23
Relationships betweenSE and other CS disciplines4. Artificial intelligence
AI -> SE–explaratory development notion caused uncertainty handling (reverse Software Engineering)–programming assistants–cognitive models
• UI design
SE -> AI–expert systems
• Separation of «known» facts by «used» rules
Ch.1 24
Relationships betweenSE and other CS disciplines5. Theoretical models
TM -> SE–Finite-state machines
• SW specification & SW design
–Petri nets• Modeling of SW and HW
–Logic• Specification languages
SE -> TM–Abstract data type notion
Ch.1 25
Relationships betweenSE and other disciplines
SE cannot be practiced in vacuum.1.Management science
– project estimation, scheduling, human resource planning
2.Systems engineering– certain laws govern the behavior of
any complex system– analysis models
Ch.1 26
Concluding remarks
! SE is an evolving engineering discipline.
– deals w/ systematic approaches to building large SW systems by teams of programmers
! We will study essential principles to the engineering activity of building SW.