overview of software engineering
DESCRIPTION
Overview of Software Engineering. CS 330 Spring 2007. Key Ingredients in successful organizations. Process. People. Customer. Technology. Pyramids are stable. Wedges are not!. A better view Process and Technology supporting people. People. Solution. Processes. Technology. - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/1.jpg)
Overview of Software Engineering
CS 330
Spring 2007
![Page 2: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/2.jpg)
Key Ingredients in successful organizations
People
Technology
Process
![Page 3: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/3.jpg)
A better viewProcess and Technology supporting people
Processes Technology
People
Pyramids are stable. Wedges are not!
![Page 4: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/4.jpg)
What is software? Computer programs and associated
documentation
Software products may be developed for a particular customer or may be developed for a general market
Software products may be– Generic/COTS - developed to be sold to a range of
different customers– Custom- developed for a customer according to their
specification
![Page 5: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/5.jpg)
Engineering
Engineering is …– The application of scientific principles and methods to the
construction of useful structures & machines Examples
– Mechanical engineering– Computer engineering– Civil engineering– Chemical engineering– Electrical engineering– Nuclear engineering– Aeronautical engineering
![Page 6: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/6.jpg)
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 it is finally beginning to arrive– Computer science one the scientific basis
• Years of studies/experience/statistics provide basis too
– Many aspects have been made systematic• Methods/methodologies/techniques• Languages• Tools• Processes
![Page 7: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/7.jpg)
Why Engineer Software ? The problem is complexity Many sources, but size is a key:
– Mozilla contains 3 Million lines of code– UNIX contains 4 million lines of code– Windows 2000 contains 108 lines of code
Second is role and combinatorics of “state” Third is uncertainty of “inputs” and their timing Fourth is the continuing changing “environment” and
demands.
Software engineering is about managing all the sources of complexity to
produce effective software.
![Page 8: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/8.jpg)
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/management
principles, techniques, tools and notations
Goal– production of quality software, delivered on time, within
budget, satisfying customers’ requirements and users’ needs
![Page 9: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/9.jpg)
What does a software engineer do?
Software engineers should – adopt a systematic and organised approach to all
aspects of software development.– use appropriate tools and techniques depending on
• the problem to be solved, • the development constraints and • the resources available
– Understand and communicate processes for improved software development within their organization
– Be effective team members and/or leaders.– Can be very technical or more managerial depending
on organizational need.
![Page 10: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/10.jpg)
What is the difference between software engineering and computer science?
Computer Science Software Engineeringis concerned with
Computer science theories are currently insufficient to act as a complete underpinning for software engineering, BUT it is a foundation for practical aspects of software engineering
theory fundamentals
the practicalities of developing delivering useful software
![Page 11: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/11.jpg)
What is the difference between software engineering and system engineering?
Software engineering is part of System engineering System engineering is concerned with all aspects of
computer-based systems development including – hardware, – software and – process engineering
System engineers are involved in system specification, architectural design, integration and deployment
![Page 12: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/12.jpg)
Difficulties?
SE is a unique brand of engineering– Software is malleable
– Software construction is human-intensive
– Software is intangible and generally invisible
– 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 “state” means behaviors can depend on history.
– Software has discontinuous operational nature
![Page 13: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/13.jpg)
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
![Page 14: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/14.jpg)
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 60%-80% of overall
development costs
![Page 15: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/15.jpg)
Economic and Management Aspects of SE
Software Engineering is about improved ROI (can be Capital and/or Social ROI)
Software production =development + maintenance
Maintenance costs 60%-80% of all (successful) development costs– 20% corrective (12%-16% total costs)– 30% adaptive (18%-24% total costs)– 50% perfective (30-40% total costs)
Quicker development is not always preferable– higher up-front costs may defray downstream costs– poorly designed/implemented software is a critical cost factor in
system cost and delays
![Page 16: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/16.jpg)
Relative Costs of Fixing Software Faults
Requirements Specification Planning Design Implementation Integration Maintenance
1 2 3 410
30
200
![Page 17: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/17.jpg)
Mythical 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– “software developers” are not interchangeable work units.
Brooks’ Law– Adding personnel to a late project makes it later
![Page 18: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/18.jpg)
Software Engineering:From Principles to Tools
PRINCIPLES
METHODS ANDTECHNIQUES
METHODOLOGIES
TOOLS
![Page 19: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/19.jpg)
Software Qualities
Qualities are goals in the practice of software engineering, and directly relate to many of the guiding principles.
External vs. Internal qualities Product vs. Process qualities
![Page 20: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/20.jpg)
Software Qualities
Critical Quality Attributes– Correctness
– Maintainability
– Dependability
– Usability
– Reliability
Other Attributes– Completeness– Compatibility– Portability– Internationalization– Understandability– Scalability– Robustness– Testability– Reusability– Customizability– Efficiency
![Page 21: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/21.jpg)
External vs. Internal Qualities
External qualities are visible to the user– reliability, usability, efficiency (maybe),
robustness, scalability
Internal qualities are the concern of developers– they help developers achieve external qualities– verifiability, maintainability, extensibility,
evolvability, adaptability, portability, testability, reusability
![Page 22: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/22.jpg)
Product vs. Process Qualities
Product qualities concern the developed artifacts– maintainability, performance, understandability,
Process qualities deal with the development activity– products are developed through process
– maintainability, productivity, predictability
![Page 23: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/23.jpg)
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/inputs– relative
![Page 24: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/24.jpg)
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
![Page 25: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/25.jpg)
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
![Page 26: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/26.jpg)
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
![Page 27: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/27.jpg)
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, distributed
programming interfaces (CORBA, DCOM), plug-in protocols, etc.
![Page 28: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/28.jpg)
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
![Page 29: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/29.jpg)
Process Principles
Prescribes all major activities Uses resources, within a set of constraints, to
produce intermediate and final products May be composed of sub-processes Each activity has entry and exit criteria Activities are organized in a sequence Has a set of guiding principles to explain goals Constraints may apply to activity, resource or
product
![Page 30: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/30.jpg)
Software Development Stages
Requirements Analysis & Specification Conceptual/System/Architectural Design Detailed/Program Design Implementation/Coding Unit & Integration Testing System Testing/Validation System Delivery/Deployment Maintenance
– Note there are many “variations” on the names. You are responsible for the main categories above (an on the next pages)..
![Page 31: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/31.jpg)
Software Lifecycle Models
Waterfall Model V Model Phased Development Model
– Incremental Model
Prototyping Model Spiral Model
![Page 32: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/32.jpg)
Software Development LifecycleWaterfall Model
Requirements
Design
Implementation
Integration
Validation
Deployment
Plan/Schedule
Replan/Reschedule
![Page 33: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/33.jpg)
V Model
REQUIREMENTSANALYSIS
SYSTEMDESIGN
PROGRAMDESIGN
CODING
UNIT & INTE-GRATION TESTING
SYSTEMTESTING
ACCEPTANCETESTING
OPERATION& MAINTENANCE
Verify design
Validate requirements
[Pfleeger 98]
![Page 34: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/34.jpg)
Phased Development Model
Development systems
Production systems
DEV
ELO
PER
SU
SER
S
Build Release 1
Use Release 1
Build Release 2
Use Release 2
Build Release 3
Use Release 3
Time
[Pfleeger 98]
![Page 35: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/35.jpg)
Software Development Lifecycle Incremental Model
Requirements Design
Implementation Integration
Validation Deployment
Requirements Design
Implementation Integration
Validation Deployment
Requirements Design
Implementation Integration
Validation Deployment
Version 1:Complete General Design
Version 2:Design/Implement first set of planned “new” features.
Note overlap with V1 schedule
Version 3:Design/Implement second set
of planned “new” features
![Page 36: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/36.jpg)
Prototyping Model
[Pressman 97]
Listen to Customer
CustomerTest-drives
Mock-up
Build/ReviseMock-Up
![Page 37: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/37.jpg)
Prototyping Model
LIST OFREVISIONS
LIST OFREVISIONS
LIST OFREVISIONS
PROTOTYPEREQUIREMENTS
PROTOTYPEDESIGN
PROTOTYPESYSTEM
TEST
DELIVEREDSYSTEMSYSTEM
REQUIREMENTS(sometimes informal
or incomplete)
reviseprototype
user/customerreview
[Pfleeger 98]
![Page 38: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/38.jpg)
Spiral development
Process is represented as a spiral rather than as a sequence of activities with backtracking.
Each loop in the spiral represents a phase in the process.
No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required.
Risks are explicitly assessed and resolved throughout the process.
![Page 39: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/39.jpg)
Spiral model of the software process
Riskanalysis
Riskanalysis
Riskanalysis
Riskanalysis Proto-
type 1
Prototype 2
Prototype 3Opera-tionalprotoype
Concept ofOperation
Simulations, models, benchmarks
S/Wrequirements
Requirementvalidation
DesignV&V
Productdesign Detailed
design
Code
Unit test
IntegrationtestAcceptance
testService Develop, verifynext-level product
Evaluate alternatives,identify, resolve risks
Determine objectives,alternatives and
constraints
Plan next phase
Integrationand test plan
Developmentplan
Requirements planLife-cycle plan
REVIEW
![Page 40: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/40.jpg)
Spiral model sectors
Objective setting– Specific objectives for the phase are identified.
Risk assessment and reduction– Risks are assessed and activities put in place to reduce
the key risks. Development and validation
– A development model for the system is chosen which can be any of the generic models.
Planning– The project is reviewed and the next phase of the spiral
is planned.
![Page 41: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/41.jpg)
Evolutionary development
Exploratory development – Objective is to work with customers and to evolve a
final system from an initial outline specification. Should start with well-understood requirements and add new features as proposed by the customer.
Throw-away prototyping– Objective is to understand the system requirements.
Should start with poorly understood requirements to clarify what is really needed.
![Page 42: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/42.jpg)
Evolutionary development
Concurrentactivities
ValidationFinal
version
DevelopmentIntermediate
versions
SpecificationInitial
version
Outlinedescription
![Page 43: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/43.jpg)
Evolutionary development Problems
– Lack of process visibility;– Systems are often poorly structured;– Special skills (e.g. in languages for rapid prototyping)
may be required.
Applicability– For small or medium-size interactive systems;– For parts of large systems (e.g. the user interface);– For short-lifetime systems.
![Page 44: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/44.jpg)
Component-based software engineering
Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems.
Process stages– Component analysis;– Requirements modification;– System design with reuse;– Development and integration.
This approach is becoming increasingly used as component standards have emerged.
![Page 45: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/45.jpg)
Reuse-oriented development
Requirementsspecification
Componentanalysis
Developmentand integration
System designwith reuse
Requirementsmodification
Systemvalidation
![Page 46: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/46.jpg)
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
![Page 47: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/47.jpg)
Different Flavors of Components
Third-party software “pieces” Plug-ins / add-ins Applets Frameworks Open Systems Distributed object infrastructures Compound documents Legacy systems
![Page 48: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/48.jpg)
Process iteration
System requirements ALWAYS evolve in the course of a project so process iteration where earlier stages are reworked is always part of the process for large systems.
Iteration can be applied to any of the generic process models.
Two (related) approaches– Incremental delivery;– Spiral development.
![Page 49: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/49.jpg)
Incremental delivery
Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality.
User requirements are prioritised and the highest priority requirements are included in early increments.
Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.
![Page 50: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/50.jpg)
Incremental development
Validateincrement
Develop systemincrement
Design systemarchitecture
Integrateincrement
Validatesystem
Define outline requirements
Assign requirements to increments
System incomplete
Finalsystem
![Page 51: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/51.jpg)
Incremental development advantages
Customer value can be delivered with each increment so system functionality is available earlier.
Early increments act as a prototype to help elicit requirements for later increments.
Lower risk of overall project failure. The highest priority system services tend to
receive the most testing.
![Page 52: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/52.jpg)
Extreme programming
An approach to development based on the development and delivery of very small increments of functionality.
Relies on constant code improvement, user involvement in the development team and pairwise programming.
Covered in Chapter 17
![Page 53: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/53.jpg)
Software Development LifecycleWaterfall Model
Requirements
Design
Implementation
Integration
Validation
Deployment
Plan/Schedule
Replan/Reschedule
![Page 54: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/54.jpg)
Software specification
The process of establishing what services are required and the constraints on the system’s operation and development.
Requirements engineering process– Feasibility study;– Requirements elicitation and analysis;– Requirements specification;– Requirements validation.
![Page 55: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/55.jpg)
Requirements
Problem Definition → Requirements/Specification– determine exactly what the customer and user need (maybe want)– Requirements develop a contract with the customer– Specification say what the software product is to do
Difficulties– client is computer/software illiterate (no idea what is doable)– client asks for wrong product (want vs need)– client is computer/software literate (specifies solution not need)– specifications are ambiguous, inconsistent, incomplete
Studies have shown that the percentage of defects originating during requirements engineering is estimated at more than 50 percent. The total percentage of project budget due to requirements defects is 25 to 40 percent.
![Page 56: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/56.jpg)
The requirements engineering process
Feasibilitystudy
Requirementselicitation and
analysisRequirementsspecification
Requirementsvalidation
Feasibilityreport
Systemmodels
User and systemrequirements
Requirementsdocument
![Page 57: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/57.jpg)
Software design and implementation
The process of converting the system specification into an executable system.
Software design– Design a software structure that realises the
specification;
Implementation– Translate this structure into an executable program;
The activities of design and implementation are closely related and may be inter-leaved.
![Page 58: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/58.jpg)
Design process activities
Architectural design Abstract specification Interface design Component design Data structure design Algorithm design
![Page 59: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/59.jpg)
The software design process
Architecturaldesign
Abstractspecification
Interfacedesign
Componentdesign
Datastructuredesign
Algorithmdesign
Systemarchitecture
Softwarespecification
Interfacespecification
Componentspecification
Datastructure
specification
Algorithmspecification
Requirementsspecification
Design activities
Design products
![Page 60: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/60.jpg)
Structured methods
Systematic approaches to developing a software design.
The design is usually documented as a set of graphical models.
Possible models– Object model;– Sequence model;– State transition model;– Structural model;– Data-flow model.
![Page 61: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/61.jpg)
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.
![Page 62: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/62.jpg)
Architecture/Design Requirements/Specification → Architecture/Design
– architecture: decompose software into modules/objects/components with interfaces
– design: develop module/object/component specifications (algorithms, data types) and communication details
– 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– “How” to achieve a requirement may be unknown
![Page 63: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/63.jpg)
Planning/Scheduling
Before undertaking cost of development, need to estimate the costs/sizes of various steps– Estimate Code size– Estimate tools needed– Estimate personnel
Often Done after Architecture and before rest of design, but revised again after full design.
Develop schedule for aspects of project lifecycle If doing predictive/quantitative SE, build on past
experience, considering how to improve process.
![Page 64: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/64.jpg)
Implementation & Integration
Design → Implementation– implement modules; verify that they meet their
specifications– combine modules according to the design– specifies how the software design is realized
Difficulties– module interaction errors– order of integration may influence quality and
productivity
![Page 65: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/65.jpg)
Programming and debugging
Translating a design into a program and removing errors from that program.
Programming is a personal activity - there is no generic programming process.
Programmers carry out some program testing to discover faults in the program and remove these faults in the debugging process.
![Page 66: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/66.jpg)
The debugging process
Locateerror
Designerror repair
Repairerror
Re-testprogram
![Page 67: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/67.jpg)
Software validation
Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer.
Involves checking and review processes and system testing.
System testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system.
![Page 68: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/68.jpg)
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
![Page 69: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/69.jpg)
The testing process
Componenttesting
Systemtesting
Acceptancetesting
![Page 70: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/70.jpg)
Testing stages
Component or unit testing– Individual components are tested independently; – Components may be functions or objects or coherent
groupings of these entities. System testing
– Testing of the system as a whole. Testing of emergent properties is particularly important.
Acceptance testing– Testing with customer data to check that the system
meets the customer’s needs.
![Page 71: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/71.jpg)
Testing phases
Requirementsspecification
Systemspecification
Systemdesign
Detaileddesign
Module andunit codeand test
Sub-systemintegrationtest plan
Systemintegrationtest plan
Acceptancetest plan
ServiceAcceptance
testSystem
integration testSub-system
integration test
![Page 72: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/72.jpg)
Quality Assurance
Done as part of each step Reduce costs by catching errors early. Help determine ambiguities/inconsistencies Help ensure quality product.
Requirements Specification Planning Design ImplementationIntegration Maintenance1 2 3 4
1030
200
![Page 73: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/73.jpg)
Deployment
Completed End-User Documentation– Separate from Developer documentation
Installation Process(es) Customer test procedures Support Processes (help desk, etc…) Trouble Tracking Repair/rework to address bugs Regression testing (as bugs are fixed)
![Page 74: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/74.jpg)
Maintenance & Evolution
Operation → Change– maintain software during/after user operation– determine whether the product still functions correctly
Difficulties– Rigid or fragile designs– lack of documentation– personnel turnover
![Page 75: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/75.jpg)
Software evolution
Software is inherently flexible and can change. As requirements change through changing
business circumstances, the software that supports the business must also evolve and change.
Although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new.
![Page 76: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/76.jpg)
System evolution
Assess existingsystems
Define systemrequirements
Propose systemchanges
Modifysystems
Newsystem
Existingsystems
![Page 77: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/77.jpg)
Why I include CASE Tools Computer Aides Software
Engineering tools support good SE processes (e.g. UML)
Some tools absolute requirement for scaling e.g. build and configuration management.
Integrated CASE (ICASE) tools embody good processes and improve productivity (E.g. Rational tool set)
Some tools (e.g. debuggers, Purify) do almost impossible for humans.
But.. Tools change– No SE tools from my first
3 jobs exist (except Fortran/C languages)
– I use regularly use 3 SE tools from my next set of jobs.
– Other tools I learned have been replaced with similar but expanded concepts.. Understanding today;s tools gives a basis for learning future ones.
![Page 78: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/78.jpg)
ICASE Design Tools
Rational Rose and Rational Unified Development.
From UML drawing to code and back.
Generates stubs and eventually testing code.
Supports multiple languages
p u b l i c c l a s s C a r {
p u b l i c D r i v e r t h e D r i v e r ;/ * *
* @ r o s e u i d 3 E A F F 1 7 E 0 3 5 B* /
p u b l i c C a r ( ) {
}}
p u b l i c c l a s s D r i v e r {
/ * ** @ r o s e u i d 3 E A F F 5 3 F 0 2 F D* /
p u b l i c D r i v e r ( ) {
}}
Car Driver
![Page 79: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/79.jpg)
Configuration Management
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– Managing simultaneous updates (team work)– Build processes with automated regression
testing– Software manufacture
![Page 80: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/80.jpg)
CM in Action
1.1
1.2
1.4
2.0
2.1
2.2
3.1
3.0
1.5
4.0
1.0
1.3
![Page 81: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/81.jpg)
Build Tools
Necessary for large projects. Keep track of what depends upon on what, and what needs recompiled or regenerated when things change.
Important even for small 1-person projects as soon as you have multiple files.
Can do much more than just “compile”, can generate document (if using code-based docs), generate manufactured code (e.g. SOAP interfaces), even send emails or suggest alternatives.
E.g. in our “IUE” project, edit some files compile was one in seconds, edit another and a rebuild taking days would be needed. If more than 30 files impacted, our make process recommend a new “branch” to avoid conflicts!
![Page 82: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/82.jpg)
Debugging Tools
How do you see what the code is really doing (not what it seems it should do)?
How to you see what happened to code during compiler optimization?
How do you find/track down the cause of Segfault/GFP in code you’ve never seen before?
How can you “test” various possibilities without generating special code or recompiling.
How do you track down a memory leak?
![Page 83: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/83.jpg)
Tools, workbenches, environments
Single-methodworkbenches
General-purposeworkbenches
Multi-methodworkbenches
Language-specificworkbenches
Programming TestingAnalysis and
design
Integratedenvironments
Process-centredenvironments
Filecomparators
CompilersEditors
EnvironmentsWorkbenchesTools
CASEtechnology
![Page 84: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/84.jpg)
The Rational Unified Process
A modern process model derived from the work on the UML and associated process.
Normally described from 3 perspectives– A dynamic perspective that shows phases over time;– A static perspective that shows process activities;– A practive perspective that suggests good practice.
![Page 85: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/85.jpg)
RUP phase model
Phase iteration
Inception Elaboration Construction Transition
![Page 86: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/86.jpg)
RUP phases
Inception– Establish the business case for the system.
Elaboration– Develop an understanding of the problem domain and
the system architecture.
Construction– System design, programming and testing.
Transition– Deploy the system in its operating environment.
![Page 87: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/87.jpg)
RUP good practice
Develop software iteratively Manage requirements Use component-based architectures Visually model software Verify software quality Control changes to software
![Page 88: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/88.jpg)
Static workflows
Workflow Description
Business modelling The business processes are modelled using business use cases.
Requirements Actors who interact with the system are identified and use cases aredeveloped to model the system requirements.
Analysis and design A design model is created and documented using architecturalmodels, component models, object models and sequence models.
Implementation The components in the system are implemented and structured intoimplementation sub-systems. Automatic code generation from designmodels helps accelerate this process.
Test Testing is an iterative process that is carried out in conjunction withimplementation. System testing follows the completion of theimplementation.
Deployment A product release is created, distributed to users and installed in theirworkplace.
Configuration andchange management
This supporting workflow managed changes to the system (seeChapter 29).
Project management This supporting workflow manages the system development (seeChapter 5).
Environment This workflow is concerned with making appropriate software toolsavailable to the software development team.
![Page 89: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/89.jpg)
Computer-aided software engineering
Computer-aided software engineering (CASE) is software to support software development and evolution processes.
Activity automation– Graphical editors for system model development;
– Data dictionary to manage design entities;
– Graphical UI builder for user interface construction;
– Debuggers to support program fault finding;
– Automated translators to generate new versions of a program.
![Page 90: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/90.jpg)
Case technology
Case technology has led to significant improvements in the software process. However, these are not the order of magnitude improvements that were once predicted– Software engineering requires creative thought - this is
not readily automated;– Software engineering is a team activity and, for large
projects, much time is spent in team interactions. CASE technology does not really support these.
![Page 91: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/91.jpg)
CASE classification
Classification helps us understand the different types of CASE tools and their support for process activities.
Functional perspective– Tools are classified according to their specific function.
Process perspective– Tools are classified according to process activities that
are supported.
Integration perspective– Tools are classified according to their organisation into
integrated units.
![Page 92: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/92.jpg)
Functional tool classification
Tool type Examples
Planning tools PERT tools, estimation tools, spreadsheets
Editing tools Text editors, diagram editors, word processors
Change management tools Requirements traceability tools, change control systems
Configuration management tools Version management systems, system building tools
Prototyping tools Very high-level languages, user interface generators
Method-support tools Design editors, data dictionaries, code generators
Language-processing tools Compilers, interpreters
Program analysis tools Cross reference generators, static analysers, dynamic analysers
Testing tools Test data generators, file comparators
Debugging tools Interactive debugging systems
Documentation tools Page layout programs, image editors
Re-engineering tools Cross-reference systems, program re-structuring systems
![Page 93: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/93.jpg)
Activity-based tool classification
Specification Design Implementation Verificationand
Validation
Re-engineering tools
Testing tools
Debugging tools
Program analysis tools
Language-processingtools
Method support tools
Prototyping tools
Configurationmanagement tools
Change management tools
Documentation tools
Editing tools
Planning tools
![Page 94: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/94.jpg)
CASE integration
Tools– Support individual process tasks such as design
consistency checking, text editing, etc. Workbenches
– Support a process phase such as specification or design, Normally include a number of integrated tools.
Environments– Support all or a substantial part of an entire software
process. Normally include several integrated workbenches.
![Page 95: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/95.jpg)
Boult’s view of SE
SE must balance risks in software development process:– Risks of error in
• requirements
• specification,
• design,
• implementation,
• and integration
– Risks of exceeding available resources
– Risks of being late on delivery or missing the market
Don’t let push for formality dominate your process. Don’t let push for expedience destroy your process.
![Page 96: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/96.jpg)
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
![Page 97: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/97.jpg)
Assessing Software Qualities
Qualities must be measurable/quantifiable Measurement requires that qualities be
precisely defined Improvement requires accurate and
consistent measurements For most SD groups, qualities are informally
defined and are difficult to assess
![Page 98: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/98.jpg)
Software Engineering “Axioms” Adding developers to a project will likely result in further delays and
accumulated costs 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 200 or more
Basic tension of software engineering– better, cheaper, faster — pick any two!– functionality, scalability, performance — pick any two!
Want/Need Management’s buy in to formal SE process. If you don’t document your process, you don’t have one!
![Page 99: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/99.jpg)
Boehm’s Spiral Model
PLAN DEVELOP AND TEST
DETERMINE GOALS,ALTERNATIVES,CONSTRAINTS
EVALUATE ALTERNATIVESAND RISKS
Requirements,life-cycle plan
Budget 1
Alternatives1
Constraints1
Risk analysis 1
Risk analysis 2
Risk analysis 3
Risk analysis 4
Constraints 2
Constraints 3
Constraints 4
Budget 2Budget 3Budget 4
Alternati
ves2
Alternati
ves3
Alternati
ves4
Prototype 1
Proto -type 2
Proto -type 3
Proto -type 4
Concept ofoperation
Softw
are
requir
emen
ts
Validated
requirements
Developmentplan
Integrationand test plan
Softw
are
desig
n
Validated,
verified design
Detaileddesign
Code
Unit test
SystemtestAcceptance
testImplementation
plan
start
![Page 100: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/100.jpg)
Key points
Software processes are the activities involved in producing and evolving a software system.
Software process models are abstract representations of these processes.
General activities are specification, design and implementation, validation and evolution.
Generic process models describe the organisation of software processes. Examples include the waterfall model, evolutionary development and component-based software engineering.
Iterative process models describe the software process as a cycle of activities.
![Page 101: Overview of Software Engineering](https://reader035.vdocuments.site/reader035/viewer/2022062721/568135d2550346895d9d3d50/html5/thumbnails/101.jpg)
Key points
Requirements engineering is the process of developing a software specification.
Design and implementation processes transform the specification to an executable program.
Validation involves checking that the system meets to its specification and user needs.
Evolution is concerned with modifying the system after it is in use.
The Rational Unified Process is a generic process model that separates activities from phases.
CASE technology supports software process activities.