This mind map is about Software Engineering. Start to use a mind map to express and organize your ideas and knowledge right now.
Similar Mind Maps
Types of risk
Version control failures
Technology failure—software doesn’t work; network failure; etc
Incompatible components at integration time
Non-appearance of team members;
Lack of skills within a group;
Overestimating people’s abilities.
People Dropping out from the course.
team changes because of course changes.
Conflict of interests during design.
Influence of deadlines and work for other second year courses;
Non-communication; confusion; not recording decisions; etc.
Non-appropriate distribution of work
Not assigning appropriate tasks to each member of the group
failures in individual Time management
Bad project time scheduling
conflict between different second year course deadlines and workloads.
Tools that do not support the project: Software incorrectly configured.
Changing requirements—perhaps the most dangerous
Bad design decisions meaning a re-design and thus delay
Non-compliance with your own glossary.
Over ambitious designs not fulfilled
Running out of storage.
Risk Identification/Likelyhood - with examples
Finding out what the new system should do
learn how people do their work
making sure your app supports there activities
Discovering the functions needed
Evaluating systems – acceptance and usability (feedback)
All the time, be "Agile" by keeping users close
Especially at the beginning, but avoid "waterfalling"
Why so hard?
Initial requirements are mostly wrong
Requirements increase the more code you write
Informal Notes become either:
Requirements Document which becomes
Refining requirements process
Kinds of requirements
functional, non-functional and domain with glossary terms highlighted
Causes of requirements change
Experience with using the software
Change in business processes/management direction
Misunderstanding and general user inconsistency.
Try and ask questions in an ordered fashion.
Your questions should move from the general to the specific.
Use feedback from one question to ask another; be prepared to ask follow up questions
Be aware of who you are asking and what they know.
Make sure the question is relevant to the person youre asking.
Ask questions that the person is qualified to answer.
Don’t assume an excessive level of technical understanding.
Phrase your questions clearly and concisely.
Don’t nag users.
Think of asking the same question in different ways at different times in an interview.
Make the intentions of the question clear.
Only ask one question at a time; multiple questions offers an opportunity not to answer.
Avoid simple yes/no answers; you’re trying to get the user to talk. The yes/no can come from post-interview analysis.
Try and avoid vague ”what if” questions Don’t be too open-ended.
Try and make questions unambiguous.
Be clear and precise; use examples to clarify questions.
You need to understand what the user is doing in their current practices.
Ask questions about how the existing practices work/dont work.
Use questions to clarify terminology
Dont let the user make unreasonable demands of the system
Don’t offer the impossible
Don’t ask what the user wants when he or she couldn’t possibly know
Don’t be rude to the client: Don’t accuse them of lying or getting it wrong; phrase your question carefully
Don’t over-use your client’s time
Primary and alternative flows ; entry and exit conditions
Entry conditions (Preconditions)
Exit Conditions (Post-conditions)
An actor is/are entities that are external to the system that directly perform "use cases". An internal DB, is not an actor.
make actor’s names actually reflect their role; ”user” is too generic; ”Fred” is too specific.
Actor names should be specific and unambiguous: ”family tree database” is more informative than ”database”.
Actors can use the system and can be used by the system
Use cases capture goals or actions of actors.
Make sure UC names contain verbs ( Create; add; modify; delete; search; report; inspect)
Looking for symmetry can help: ”create” must be matched by ”delete”.
remember fundamental things: ”a user will read a document; will look at a picture; etc.”
This means avoiding mindless detail—”genealogist presses mouse button”.
Each UC should be self-contained.
try and be precise and avoid vagueness. ‘who is doing x’; ’what y is being done'; 'how is z being done?';
Avoid the passive voice in descriptions; it leaves open the questions as to who is doing what
Don’t repeat the use case name in the entry condition. eg ”Print document” has "doc exists" not "ready to print"
Don’t make up UC not in the requirements. ”add person” subsumes ”add father”
Avoid UC that look like algorithm steps: for example, save tree, enter tree
A use case diagram should look like a star, not an activity diagram.
Name the System box and, again, make it informative.
system should be a black box.
UC diagrams show what use cases exist, including choice points and parrallelism. but not necessarily how they are related.
Activity diagrams show a flow-chart process of the system.
fine grained task
what do the arrows mean: control; data flow; initiating actor
wrong level of abstraction: Fine at start; big at end
main flow is normal; alternative catches deviations in AF should still meet
goal(pay by cheque rather than credit card)
exceptional flow is not meeting goal (card doesn’t work)
including too much UI
building data structure
Do's and don'ts
Used to model the DOMAIN
From DOMAIN to DESIGN
Domain classes often inspire design classes
Some domain classes represent entities outside the software (e.g. actors).
Extra design classes – Pure Fabrications - are often added, e.g. to represent collections.
The key skill required is assigning responsibilities to (software) classes.
Used to model the SPECIFICATION & DESIGN
more detailed than domain class diagrams
include operations as well as attributes
include software-oriented things such as types and visibilities.
deal with a small number of classes at once, since each is described in more detail.
Extra UML features
Types. Shown after the name, e.g. name:String
Visibilities + (public) – (private)
Parameters on operations e.g. addOption(option: MCQOption)
Static attributes and operations e.g. inputFromFile(filename:String):Question
Constructors: Student(name, ID)
Types and visibilities are still optional
Used to document ACTUAL CODE
Class Diagrams - Show classes and their relationships
Answers to quiz here and vocab What, in the context of software processes, is “ceremony”?What is the aim of a formal/rigorous development process?What is the Blank Tape Trick?What is Analysis Paralysis?What is a unit test?What is the idea behind programming in pairs?What is refactoring?What led to UML becoming a widely accepted standard notation?What is rapid prototyping?What is domain modelling?
Later a problem is found, the more expensive it costs to fix
Well defined milestones/deliverables make budgeting/planning easier
Well documented, problems clearly identified
Promotes specilisation because of layers
Deliverables offen late or fudged (blank tape trick)
Analysis Paralysis offen occurs
Specialisation can cause poor communication.
The system delivered does not meet the users’ needs
“maintenance” phase is often prolonged and traumatic.
project is usually grossly late and over-budget.
you won’t get the requirements right the first time
Ceremony is absolute minimum and
respond in an “agile” way to changing requirements
Iterative – consist of short cycles where part of the software is produced.
Frequent interactions with the customer.
Strong emphasis on testing
Done in small “self-organising” teams with little specialisation or explicit leadership
Best known are Extreme Programming (XP) and SCRUM.
cope much better with requirements change than waterfall
code quality should be good
requires competence and confidence from all developers
long-term planning may be difficult
lack of documentation may cause problems later
probably not suitable for large projects
About Agile methods
Extreme programming (XP)
Requirements are determined from “user stories” (similar to informal use cases)
Customer representative always available
Unit tests are written before the code to be tested
Programming in pairs – one codes the other reviews, swapping frequently.
Strong emphasis on simplicity of design.
“Refactor whenever and wherever possible”
Example of an Agile Method
The Unified Process (UP)
Timeboxed, typically 4-6 weeks.
Each iteration produces a production version of a subset of the system
Requirements gathering (WS 1 and 2)
domain modelling (WS3)
class design (WS4)
coding, testing etc
What we are learning
Lack of user involvement.
Lack of resources.
Lack of executive support.
Changing requirements & specifications.
Lack of planning.
Elimination of need for project.
Lack of IT management.
FAILURE of software projects:
Allowing users to achieve a goal with efficiency, effectiveness and satisfaction
Utility is the functionality of a system
Utility without usability, but not vice versa
Have paradigms of good usability, e.g. GUI
Often the last thing and not enough time
Can design a UI as soon as the functionality is known
Early prototyping; keeping it Agile
Also helps force requirements questions
The user interface widgets that you commonly use
There are many styles for deploying these widgets in a UI
Some are not based on WIMPS
The user interface designer’s skill is choosing a design that affords the functionality
A different skill from programming
Some people would claim disjointness in the two skill sets
Visibility of system status System should always keep users informed
Match between system and the real world System should speak the user's language
System functions chosen by mistake need a clear 'emergency exit'
Consistency and standards Avoid ambiguity
Recognition rather than recall
Flexibility and efficiency of use
Aesthetic and minimalist design
recognize, diagnose and recover from errors
Help and documentation
Has mental models of goals and intentions
The human recieves information; forms intentions and executes actions with tools in the world
The human “information processor” has limitations
Brilliant at association and inference
Limited memory: The famous 7 plus or minus two
Physical limitations – finger span, tiredness
Cycle of Execution and Evaluation
Good at long, repetitive task (at which humans are poor)
Rubbish at inference and association
Human vs computer
Human <3 Computer - Basics
Defined start point
Restricted set of known steps
Set of known options
Ability to move back and forth and change options
One choice affects what is offered for another
Typical of an installation process
Again, set of known step and known options
No defined start point
I might want to start anywhere
Choosing Specifying a package holiday: Start point; end point; dates; hotels; tours; etc.
I might wish to start at any point
One choice affects another
Direct Manipulation Interface
Humans work by manipulating things both mentally and physically
A user reaches for what he/she wants, uses and puts it down again
Humans also wish to see the results of their actions
Dragging a file to the printer; putting files in the bin; making words bold; drawing lines etc.
“hey you do that”
Lots of functionality available all the time
Command line interface
Typicall not for everyday users
Very good for mass action
“mv *.txt ../other-folder”
Very good for constructing arbitrary, complex actions
Often very fast for the power user
A set of repeated steps
Need to be run repeatedly in the same way
“A batch” of commands
Don’t necessarily need to interact as the process runs
Bbut do need feedback like logs
Still an interaction style
Styles of UI
Ergonomics of a typical GUI
Long-term modes modes
Short term “spring-loaded” modes
Alert modes modes
Modes that emulate a real-life situation that is itself modal
Modes that change the attributes of something
Modes that stop functionality, as in error conditions
There should be a clear indicator of the current mod
It should be easy to change modes
Try to be modeless, but some are useful
Ease to learn; easy to remember
return after long break and know how to use the tool
return after a short break (cup of tea) and apprehend state
Consistent application design
Closeness to user’s model of the task helps mapping
Most users don’t read manuals
Users prefer to learn by playing or exploring
Therefore good presentation of model to user is vital
“Walk up and use”
Users like to explore
Recall vs Recognition
External consistency: Consistency with task
Internal consistency: Arbitrary consistency
Does the UI map from all parts of task model to system model?
Can the system do things that I cannot ask it to do?
Can the input reach the(and only the) necessary states of the system ?
Match task analysis or activity diagrams to use cases and class/collaboration diagrams
Small cost to user, larger cost in implementation
Ease of Evaluation
Translate state from core to output language
Must preserve state attributes in terms of domain concepts
Output language often limited in expressivity
Video simply limited in size – difficult to see context in documents etc.
Simple and natural dialogue
Speak the user's language
Minimize user memory load
Provide clearly marked exits
Provide short cuts
Good error messages
Safety critical systems
Provides graceful degradation: don’t have to revert to manual control immediately with one computer out.
Gives continuous testing for free – each discrepancy reveals a bug! system will become be extremely reliable
two computers with different software written by different teams. In theory both will fail at the same time
But if there is a discrepancy you don’t know which one’s wrong – so you need a third computer and take a majority vote: triple redudancy.
Basic testing techniques
Traditional solution: have a separate testing team who are as nasty to the software as possible
Agile solution – write the tests before the code – also helps to clarify requirements.
Equivalence partitioning: Focus on space BOUNDARIES instead of all values, since exhaustive testing is impossible
Means tests will be written without preconceptions about how the code works.
If the code is changed, the same tests are still valid.
Allows more tests to be done
Allows tester to apply pressure to those places which look most likely to break.
Kinds of testing
Relatively simple, but the class you’re testing will usually rely on other classes.
The search space is generally well defined so techniques like EP ad BVA are most useful here.
Often possible to be systematic and reasonably confident that a single class is bug-free.
In Java, often done with the JUnit testing framework.
Harder to define than unit testing; shape of testing space is less obvious.
Check that the use cases can be performed without problems.
This will generally be a lot more varied than the context in which it was developed.
May involve different hardware, operating systems, performance issues etc.
Need to check the documentation and procedures as well as the code.
In general, users don’t really know in advance what they want (the “waterfall fallacy”).
Who within the customer organisation defines the spec? e.g. Managers and end users will have different views.
Fixating on passing the acceptance test could result in serious problems being missed.
Applies to all non-trivial(>10k lines) projects
Some components of SW will be bug-free
Kinds of bugs
Fail to provide functionally the user needs
Failure to conform non-function requirements
Inappropriate UI design
Help against bugs
If it isn't working properly, refactor.
Split classes, move methods, replace algo's etc
Frequent contact with users and stakeholders
Bug density factors
On average, 3-5 bugs per 100 lines
concurrent, reactive systems are more diffcult than sequential transformations systems
Programming language: Java < C < Perl
Programmer competence and experience
Good designs should:
Is easy to test
Is easy for other developers to understand
Adapts well to changing requirements
(Usually) one which is object-oriented.
Provide guidance on assignment of responsibilities to classes – the core skill in OO design.
Follows “Gang of Four” design patterns
A good design should:
contain an explanation of when and how it is applicable
Have names, (e.g. Composite) used to communicate rapidly between designers
Also good for passing on wisdom to inexperienced designers.
Good patterns should:
High cohesion/low coupling
High cohesion: a class represents a single well-defined entity
Low coupling: class interacts with as few other classes as reasonably possible.
Subtype polymorphism (inheritance)
Many beginners misuse/overuse inheritance
“is-a-kind-of” relationship between superclass and subclasses.
DON’T use inheritance to avoid code duplication if the is-a-kind-of test fails
Often, other classes only need to be coupled to the superclass
Operations, e.g. addReview() can be implemented once in the superclass…
More subclasses (e.g. CD) can be added without changing (or even recompiling) existing code.
Some coupling is essential but avoid spaghetti-type links between classes.
Always separate internal data structures (model) from the UI code (view)
Allow each to change without affecting the other
Could also be a MVC where the controller is between M and V