Please enable JavaScript.
Coggle requires JavaScript to display documents.
Introduction to Software Engineering (TM354) (Decomposition (Modules…
Introduction to Software Engineering (TM354)
Problems
Problems with software
It doesn't meet requirements
It's unreliable
It's delivered late
Problems with projects
Late, over budget, and cancellations
Causes
Poor understanding of requirements
Lack of user involvement
Lack of clear business objectives
Over building
Lack of agile support
The later problems are encountered the more expensive they are to fix
The development process
Phases
Domain modelling / 2. requirements / 3. design / 4. implementation / 5. testing / 6. integration / 7. maintenance / 8. project management / 9. quality management
As an engineering activity
Quality (VVT)
validation / verification / testing
Standards are used
A code of practice is used
Developers play roles
There is a defined process, and needs to meet a set of requirements
What is it?
A set of rules that define how development should be carried out
A set of software engineering activities
Incorporates a process model
A process model incorporates all the activities throughout the
entire life
of the project - not just one cycle
Increments
Increments can be developed in parallel
An increment is a single life cycle, and is generally timeboxed
An
iteration
is done over a single activity
Level of formality
Different projects have different needs
Governmental projects may require standards and guidelines to be followed - resulting in a formal process (more documentation)
Financial institutions may require quick development time and require a more informal (less documentation; agile) process
Decomposition
Breaking a problem into smaller more manageable pieces, until it can be comprehended by an individual
Modules
Libraries / classes / whole applications
Properties of a maintainable module (HAIL)
Helps deal with growing system complexity - lowers cost, maintainability, quality etc.
Systems are decomposed into modules
Cohesion
High cohesion: one major abstraction / a more pronounced purpose
Coupling
The degree of interdependence :
Look for patterns and draw boundaries around them
Interfaces
Contract (DPI)
Describes what it does, and what it needs
Promotes reuse, and can be a possible standard
Circular dependencies
Abstraction
Abstraction is a particular way of viewing a problem, then arriving at a useful decomposition.
A problem is fully abstracted when if the interface encapsulates all the necessary behaviour
Maintainability
Maintainable software should.. (WADD)
have
A
dopted standards
be
D
esigned well
be
W
ritten well
be
D
ocumented
A maintainable module should have.. (HAIL)
Maintainability can be measured with..
How long it takes to fix bugs
The effort it takes to adapt the system for current needs
Legacy systems (COLD TM)
Properties:
C
ritical to business;
O
ld;
L
arge; lack of
D
ocumentation; developed with outdated
T
echniques; difficult to
M
aintain
Malleability means software is easy to change, and easy to introduce errors over time
Concerns when replacing legacy systems
Staff retraining
Maintaining service continuity
Staff turnover means lack of maintenance
Risk management
The spiral model
the process
Develop and verify a partial
solution
or product
Determine the
objectives
, the alternatives, and the constraints
Review
the solution and
plan
the activities for the next iteration
Evaluate
the objectives; identify and resolve the associated risks
Similar to agile - they share a lot in common. Analysis, design, implementation, and testing can be transplanted onto this spiral. Review the images in your notes, or paste them here
Agile
Agile is a risk drive model as mitigation of risk is an important concern with it
Involving customers throughout the process reduces risk as it avoids BDUF
Risk: e.g. time-to-market is a risk