1
|
|
2
|
- 7.1 The Software Engineering Discipline
- 7.2 The Software Life Cycle
- 7.3 Modularity
- 7.4 Design Methodologies
- 7.5 Tools of the Trade
- 7.6 Testing
- 7.7 Documentation
- 7.8 Software Ownership and Liability
|
3
|
|
4
|
|
5
|
|
6
|
- Researchers
- Practitioners
- Theoreticians
- Professional organizations: ACM, IEEE, etc.
- Codes of professional ethics
- Standards
|
7
|
- Changes often introduce more problems than they solve.
- Research addressing this problem currently focuses primarily on
improving initial software development.
|
8
|
- Create system from design
- Write programs
- Create data files
- Develop databases
|
9
|
- Module testing: single module
- Often uses simplified simulators of other modules called stubs
- System testing: entire program
- Extremely difficult to perform successfully
- Significant open topic of research
|
10
|
- Waterfall model
- Incremental model
- Evolutionary prototyping
- Throwaway prototyping
- “Extreme programming”
|
11
|
- Project planning
- Project management
- Documentation
- Prototyping and simulation
- Interface design
- Programming
|
12
|
- Structure chart: displays relationships between components of a
procedural design
- Class diagram: displays relationships between classes in an
object-oriented design
- Collaboration diagram: an enhanced class diagram
|
13
|
|
14
|
|
15
|
|
16
|
|
17
|
- Goal: minimize coupling and maximize cohesion
- Coupling: interactions between modules
- Cohesion: internal binding within a module
|
18
|
- Control coupling: one module passes control to another
- Data coupling: sharing of data between modules
- Implicit coupling: hidden coupling; frequently causes errors
- Global data =3D data accessible to all modules
- Side effects =3D action performed by a procedure that is not readily
apparent to its caller
|
19
|
- Logical cohesion: logical similarity between actions and components<=
/li>
- Functional cohesion: components are focused around performance of a
single activity
- Stronger than logical cohesion
- Cohesion in object oriented systems
- Entire object will naturally be logically cohesive
- Each method should be functionally cohesive
|
20
|
|
21
|
- Top-down design
- Generates cohesive, modular designs
- Bottom-up design
- Generates reusable modules
|
22
|
- Design patterns
- Template libraries
- Design patterns implemented as objects
- Component architecture
- Multi-object components that can be assembled into complete program=
s
- Open-source development
- Public evolutionary prototyping
|
23
|
- Dataflow diagram: displays how data moves through a system
- Entity-relationship diagram: displays relationships between entities=
in
a system
- Relationship types
- One-to-one
- One-to-many
- Many-to-many
|
24
|
|
25
|
|
26
|
|
27
|
- Glass-box testing
- Pareto principle
- Basis path testing
- Black-box testing
- Boundary value analysis
- Redundancy testing
- Beta testing
|
28
|
- User documentation
- Printed book for all customers
- On-line help modules
- System documentation
- Source code
- Structure and naming conventions
- Comments
- Design documents
- CASE tools can help keep these up to date
|
29
|
- Copyright
- Test =3D “substantial similarity”
- Filtration criteria: what is not copyrightable
- Features covered by standards
- Characteristics dictated by software purpose
- Components in the public domain
- “Look and feel” argument occasionally succeeds
|
30
|
- Patents
- Mathematical formulae are traditionally unpatentable
- Recent exceptions for some algorithms
- Trade secrets
- Non-disclosure agreements are legally enforceable
|