Tcss 360, Spring 2005 Lecture Notes: Software Engineering And The Software Lifecycle
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Tcss 360, Spring 2005 Lecture Notes: Software Engineering And The Software Lifecycle as PDF for free.
More details
- Words: 1,155
- Pages: 20
TCSS 360, Spring 2005 Lecture Notes Software Engineering and the Software Lifecycle
1
Software engineering
Software engineering: the profession, practiced by developers, concerned with creating and maintaining software applications by applying technologies and practices from computer science, project management, and other fields.
Software engineering has accepted as its charter, "How to program if you cannot." -- E. Dijkstra The first step toward the management of disease was replacement of demon theories and humours theories by the germ theory. That very step, the beginning of hope, in itself dashed all hopes of magical solutions. It told workers that progress would be made stepwise, at great effort, and that a persistent, unremitting care would have to be paid to a discipline of cleanliness. So it is with software engineering
2
Roles of people in software
people involved in software production
customer / client: wants software built
managers / designers: plan software
difficult to foresee all problems and issues in advance
developers: write code to implement software
often doesn't know what he/she wants
it is hard to write complex code for large systems
testers: perform quality assurance (QA)
it is impossible to test every combination of actions
3
Problems with software today
Example: Space shuttle software
cost: $10 Billion, millions of dollars more than planned time: 3 years late quality: first launch of Columbia was cancelled because of a synchronization problem with the Shuttle's 5 onboard computers
error was traced back to a change made 2 years earlier when a programmer changed a delay factor in an interrupt handler from 50 to 80 milliseconds the likelihood of the error was small enough, that the error caused no harm during thousands of hours of testing substantial errors still exist in the code
astronauts are supplied with a book of known software problems "Program Notes and Waivers"
reusabilty: shuttle software cannot be reused
4
Ad-hoc software development
ad-hoc development: creating software without any formal guidelines or process
what are some disadvantages of ad-hoc development? some important actions (testing, design) may go ignored not clear when to start or stop doing each task does not scale well to multiple people not easy to review or evaluate one's work 5
The software lifecycle
software lifecycle: series of steps / phases, through which software is produced
goals of each phase:
can take months or years to complete
mark out a clear set of steps to perform produce a tangible document or item allow for review of work specify actions to perform in the next phase
common observation: The later a problem is found in software, the more costly it is to fix 6
Lifecycle phases standard phases
Requirements Analysis & Specification Design Implementation, Integration Testing, Profiling, Quality Assurance Operation and Maintenance
other possible phases
risk assessment: examining what actions are critical and performing them first (part of Spiral model) prototyping: making a quick version of the
7
One view of SW cycle phases Requirements Elicitation
Analysis
Expressed in Terms Of
System Design
Structured By
Object Design
Implemen tation
Implemented By Realized By
Verified By class... class... class...
Use Case Model
Application Subsystems Domain Objects
Testing
Solution Domain Objects
Source Code
? class.... ? Test Cases
8
Some software models
Several models for developing software (besides ad-hoc) have been attempted:
code-and-fix: write some code, debug it, repeat until finished evolutionary: build initial requirement spec, write it, then "evolve" the spec and code as needed waterfall: perform the standard phases (requirements, design, code, test) in sequence rapid prototyping: write an initial "throwaway" version of the product, then design, code, test 9
code-and-fix model Code First Version Modify until Client is satisfied Operations Mode
Retirement 10
Problems with code-andfix
What are some reasons not to use the code-and-fix model?
code becomes expensive to fix (bugs are not found until late in the process) code didn't match user's needs (no requirements phase!) code was not planned for modification, not flexible
11
Evolutionary model Requirements Verify
Arch. Design Verify
For each build: Perform detailed design, implement. Test. Deliver.
Operations
Retirement
12
Problems with evolutionary
The evolutionary model is similar to code-andfix, but it assumes the repetitions are "evolutions" of the code, not necessarily bug fixes. Problems with this?
difficult to distinguish from code-and-fix assumes user's initial spec will be flexible; fails for:
separate pieces that must then be integrated "information sclerosis": temporary fixes become permanent constraits bridging; new software trying to gradually replace old 13
Waterfall model (Royce, 1970) Req. Change
Requirements Verify
Design Verify
Implementation Test
Operations
Retirement 14
Rapid prototyping model Req. Change
Rapid Prototype Verify
Redesign Verify
Re-implementation
Test
Operations
Retirement 15
Waterfall / Prototyping issues
The waterfall models (with or without prototyping) are perhaps the most common model for software development
we will use waterfall in this course!
What are some positives and negatives about this method?
+ formal, standard, has specific phases with clear goals + good feedback loops between adjacent phases - rigid, too linear; not very adaptable to change in the product - requires a lot of planning up front (not always easy /
16
Spiral model (Boehm) Cumulative cost Progress through steps
Determine objectives, alternatives, constraints (OAC) Concrete Specification OAC Abstract Specifcation OAC Requirements OAC
Commit Review partition
Risk Assessment Risk Assessment Risk Assessment Risk Control
Evaluate alternatives, identify, resolve risks t et en S m em ge I t an a k s Ri isk M R
Risk Control
Requirements Concept of Plan Operation Requirements Abstract Abstract Specification Specification Plan Requirements Validation Concrete Specification Plan Abstract Specification Validation
Plan next phases
Software Development Plan
Concrete Specification Validation and Verification
an Pl
Risk Control
Concrete Specification
Develop, verify nextlevel product
17
Another view of spiral model Risk Assessment Requirements Verify
Req. Change Risk Assessment Design Verify
Risk Assessment Implementation Test
Adds a Risk Analysis step to each phase (phases may not be completed in this order any more!)
Operations
Retirement 18
Spiral model problems
What are some positives and negatives about this method?
+ focuses attention on reuse + accommodates changes, growth + eliminates errors and unattractive choices early + limits to how much is enough (not too much design, reqs, etc) + treats development, maintenance same way - matching to contract software (doesn't work well when you're bound to a fixed inflexible contract) - relying on developers to have risk-assessment expertise - need for further elaboration of project steps (clearer
19
Tools for software engineers
CASE (Computer-Aided Software Engineering)
requirements / spec generation software design diagram (UML) software integrated development environments (IDEs) test suites (JUnit) and benchmarking / profiling software
20
1
Software engineering
Software engineering: the profession, practiced by developers, concerned with creating and maintaining software applications by applying technologies and practices from computer science, project management, and other fields.
Software engineering has accepted as its charter, "How to program if you cannot." -- E. Dijkstra The first step toward the management of disease was replacement of demon theories and humours theories by the germ theory. That very step, the beginning of hope, in itself dashed all hopes of magical solutions. It told workers that progress would be made stepwise, at great effort, and that a persistent, unremitting care would have to be paid to a discipline of cleanliness. So it is with software engineering
2
Roles of people in software
people involved in software production
customer / client: wants software built
managers / designers: plan software
difficult to foresee all problems and issues in advance
developers: write code to implement software
often doesn't know what he/she wants
it is hard to write complex code for large systems
testers: perform quality assurance (QA)
it is impossible to test every combination of actions
3
Problems with software today
Example: Space shuttle software
cost: $10 Billion, millions of dollars more than planned time: 3 years late quality: first launch of Columbia was cancelled because of a synchronization problem with the Shuttle's 5 onboard computers
error was traced back to a change made 2 years earlier when a programmer changed a delay factor in an interrupt handler from 50 to 80 milliseconds the likelihood of the error was small enough, that the error caused no harm during thousands of hours of testing substantial errors still exist in the code
astronauts are supplied with a book of known software problems "Program Notes and Waivers"
reusabilty: shuttle software cannot be reused
4
Ad-hoc software development
ad-hoc development: creating software without any formal guidelines or process
what are some disadvantages of ad-hoc development? some important actions (testing, design) may go ignored not clear when to start or stop doing each task does not scale well to multiple people not easy to review or evaluate one's work 5
The software lifecycle
software lifecycle: series of steps / phases, through which software is produced
goals of each phase:
can take months or years to complete
mark out a clear set of steps to perform produce a tangible document or item allow for review of work specify actions to perform in the next phase
common observation: The later a problem is found in software, the more costly it is to fix 6
Lifecycle phases standard phases
Requirements Analysis & Specification Design Implementation, Integration Testing, Profiling, Quality Assurance Operation and Maintenance
other possible phases
risk assessment: examining what actions are critical and performing them first (part of Spiral model) prototyping: making a quick version of the
7
One view of SW cycle phases Requirements Elicitation
Analysis
Expressed in Terms Of
System Design
Structured By
Object Design
Implemen tation
Implemented By Realized By
Verified By class... class... class...
Use Case Model
Application Subsystems Domain Objects
Testing
Solution Domain Objects
Source Code
? class.... ? Test Cases
8
Some software models
Several models for developing software (besides ad-hoc) have been attempted:
code-and-fix: write some code, debug it, repeat until finished evolutionary: build initial requirement spec, write it, then "evolve" the spec and code as needed waterfall: perform the standard phases (requirements, design, code, test) in sequence rapid prototyping: write an initial "throwaway" version of the product, then design, code, test 9
code-and-fix model Code First Version Modify until Client is satisfied Operations Mode
Retirement 10
Problems with code-andfix
What are some reasons not to use the code-and-fix model?
code becomes expensive to fix (bugs are not found until late in the process) code didn't match user's needs (no requirements phase!) code was not planned for modification, not flexible
11
Evolutionary model Requirements Verify
Arch. Design Verify
For each build: Perform detailed design, implement. Test. Deliver.
Operations
Retirement
12
Problems with evolutionary
The evolutionary model is similar to code-andfix, but it assumes the repetitions are "evolutions" of the code, not necessarily bug fixes. Problems with this?
difficult to distinguish from code-and-fix assumes user's initial spec will be flexible; fails for:
separate pieces that must then be integrated "information sclerosis": temporary fixes become permanent constraits bridging; new software trying to gradually replace old 13
Waterfall model (Royce, 1970) Req. Change
Requirements Verify
Design Verify
Implementation Test
Operations
Retirement 14
Rapid prototyping model Req. Change
Rapid Prototype Verify
Redesign Verify
Re-implementation
Test
Operations
Retirement 15
Waterfall / Prototyping issues
The waterfall models (with or without prototyping) are perhaps the most common model for software development
we will use waterfall in this course!
What are some positives and negatives about this method?
+ formal, standard, has specific phases with clear goals + good feedback loops between adjacent phases - rigid, too linear; not very adaptable to change in the product - requires a lot of planning up front (not always easy /
16
Spiral model (Boehm) Cumulative cost Progress through steps
Determine objectives, alternatives, constraints (OAC) Concrete Specification OAC Abstract Specifcation OAC Requirements OAC
Commit Review partition
Risk Assessment Risk Assessment Risk Assessment Risk Control
Evaluate alternatives, identify, resolve risks t et en S m em ge I t an a k s Ri isk M R
Risk Control
Requirements Concept of Plan Operation Requirements Abstract Abstract Specification Specification Plan Requirements Validation Concrete Specification Plan Abstract Specification Validation
Plan next phases
Software Development Plan
Concrete Specification Validation and Verification
an Pl
Risk Control
Concrete Specification
Develop, verify nextlevel product
17
Another view of spiral model Risk Assessment Requirements Verify
Req. Change Risk Assessment Design Verify
Risk Assessment Implementation Test
Adds a Risk Analysis step to each phase (phases may not be completed in this order any more!)
Operations
Retirement 18
Spiral model problems
What are some positives and negatives about this method?
+ focuses attention on reuse + accommodates changes, growth + eliminates errors and unattractive choices early + limits to how much is enough (not too much design, reqs, etc) + treats development, maintenance same way - matching to contract software (doesn't work well when you're bound to a fixed inflexible contract) - relying on developers to have risk-assessment expertise - need for further elaboration of project steps (clearer
19
Tools for software engineers
CASE (Computer-Aided Software Engineering)
requirements / spec generation software design diagram (UML) software integrated development environments (IDEs) test suites (JUnit) and benchmarking / profiling software
20
Related Documents
Software Lifecycle
November 2019 20
Software Engineering
December 2019 49
Software Engineering
June 2020 10
Software Engineering
June 2020 9
