Software Engineering

Risk Planning
Risk Identification/Likelyhood - with examples
Types of risk
Basics
Refining requirements process
Interview Guidelines
Interview tips
Class Diagrams - Show classes and their relationships
Do's and don'ts
Old way!
FAILURE of software projects:
Example of an Agile Method
About Agile methods
What we are learning
Good designs should:
A good design should:
Good patterns should:
GRASP
MVC
Triple Redundancy
Basic techniques
Unit Testing
Human <3 Computer - Basics
Human vs computer
About HCI
Styles of UI
Try to be modeless, but some are useful
UI aims
Users like to explore
Software Engineering
Understand/solve problemsiteratvely and incrementall...
Risks Assesment
Project risks
project schedule or reso...
Product risks
quality or performance of...
Business risks
organisation developing o...
Technology risks:
software or hardware technolo...
Version control failures
Technology failure—software doesn’t work; network failure; etc
Incompatible components at integration time
People risks:
people in the developme...
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.
Organisational risks:
organisational environment where t...
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 risks:
CASE tools and other s...
Tools that do not support the project: Software incorrectly configured.
Requirements risks:
changes to the customer requirem...
Changing requirements—perhaps the most dangerous
Bad design decisions meaning a re-design and thus delay
Non-compliance with your own glossary.
Estimation risks:
management estimates of the ...
Over ambitious designs not fulfilled
Running out of storage.
Avoidance strategies:
probability that the risk will arise wil...
Minimisation strategies:
impact of the risk will be reduced.
Contingency plans:
are prepared for the worst and h...
Requirements Gathering
Approach:(Pull apart & probe and repeat & revisit re...
Why?
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)
When?
All the time, be "Agile" by keeping users close
Especially at the beginning, but avoid "waterfalling"
Where?
Questioning
Better if "situatied" - at t...
Workplace
To see what they use ...
Why so hard?
Initial requirements are mostly wrong
Requirements increase the more code you write
Sargeant's rule
(Outstanding Requirements...
Refining requirements
Informal Notes become either:
Glossary
Requirements Document which becomes
Use Cases
Business Rules
Kinds of requirements
-- Somnerville
Funtional
processes(behaviour...
Non-Functional Requirements
Constraints on the services or functions offere...
Domain Requirements
Characteristics and constraints of a ...
User Requirements
Statement and diagrams of what ...
System Requirements
functionsservices and operational c...
Presenting requirements
prioritisable MoSCOW
Must; Should; COuld; Would like
functional, non-functional and domain with glossary terms highlighted
Causes of requirements change
Experience with using the software
(“The UI is too complex…”)
Change in business processes/management direction
Marketing requirements
(“I would buy it if…”)
Technology change
Standards/regulations/certificatio...
Misunderstanding and general user inconsistency.
Interview guidelines
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
UML
Unified Modelling La...
Use Cases
Capture functionality ...
Description
(Details)Casual(descrip...
Primary and alternative flows ; entry and exit conditions
Entry conditions (Preconditions)
Exit Conditions (Post-conditions)
Actors involved
Actors
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
Cases
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.
Whole thing
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.
Common errors
bad names
fine grained task
chaining
missing uc
wrong uc
mis-identified actor
missing actor
mis-named actor
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
Used to model the DOMAIN
DOMAIN objectsNOT SW objects
From DOMAIN to DESIGN
Domain classes often inspire design classes
“lowered representational gap” but they don’t usually correspon...
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
SOFTWARE objects
Design Modelling
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
Javadoc would be better used
Software processes
Waterfall Development
Development
Requirements gathering
Systems analysis
Design
Coding
Testing
Maintenance
Motivation
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
Common problems
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
on average 45% of the features specified are never used (Larman).
“maintenance” phase is often prolonged and traumatic.
project is usually grossly late and over-budget.
FAIL because:
you won’t get the requirements right the first time
don't get constant feedback from user hence wrong direction from the start
Agile methods
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.
pros
cope much better with requirements change than waterfall
code quality should be good
cons
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
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”
The Unified Process (UP)
same guys who made UMLclose to indu...
Iterative
Timeboxed, typically 4-6 weeks.
if you don’t get it done you don’t extendyou cha...
Each iteration produces a production version of a subset of the system
not rapid prototypingbut allows for user feedback
Phases
Corrispond to wa...
Inception.
Initial “feasibility stu...
Elaboration.
More detailed studypro...
Construction.
The bulk of the work. Itera...
Transition.
Acceptance testing“...
Disiplins
Requirements gathering (WS 1 and 2)
domain modelling (WS3)
class design (WS4)
coding, testing etc
Artefacts
don’t produce more ...
UML diagrams
reports
code
other deliverables
Incomplete requirements.
Lack of user involvement.
Lack of resources.
Unrealistic expectations.
Lack of executive support.
Changing requirements & specifications.
Lack of planning.
Elimination of need for project.
Lack of IT management.
Technology illiteracy.
Design
Is simple
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
Patterns
A goodresusable d...
be reused.
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.
Follows GRASP
General Responsibility Assi...
High cohesion/low coupling
High cohesion: a class represents a single well-defined entity
Bus or Driver but not BusAndDriver
Low coupling: class interacts with as few other classes as reasonably possible.
Polymorphism
Reduces coupling
Subtype polymorphism (inheritance)
public class Elephant extends Animal ("Is-a" test)
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
Insteadput the shared code somewhere else (usually in another class)
Often, other classes only need to be coupled to the superclass
(e.g. CourseReview coupled to ReadingMaterialnot Book and Chapter).
Operations, e.g. addReview() can be implemented once in the superclass…
Or can be made abstract and implemented differently in each subclass.
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.
M-V separation
Model-View
Always separate internal data structures (model) from the UI code (view)
Allow each to change without affecting the other
GRASP Protectied Varations
Could also be a MVC where the controller is between M and V
Model-View-Controller
Testing
successful test is one w...
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.
Process
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
close to 0close to MAX0negatives etc
Black box
testing without acce...
Means tests will be written without preconceptions about how the code works.
If the code is changed, the same tests are still valid.
White box
testing with access to...
Allows more tests to be done
Allows tester to apply pressure to those places which look most likely to break.
Kinds of testing
Unit testing
Testing one unit – class...
Relatively simple, but the class you’re testing will usually rely on other classes.
In general almost all software relies on other software (e.g. Java library classes).
The search space is generally well defined so techniques like EP ad BVA are most useful here.
Equivalence partitioning & Boundary Value Analysis
Often possible to be systematic and reasonably confident that a single class is bug-free.
In Java, often done with the JUnit testing framework.
Integration testing
Testing that the components of ...
Harder to define than unit testing; shape of testing space is less obvious.
Check that the use cases can be performed without problems.
Focus on UC is more important here
Regression
Testing after a change ...
Smoke testing
repeat the most critical tes...
System testing
testing in the context it will ...
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.
Alpha testing
a small group of usersdo...
Beta testing
a wider groupaway from...
Acceptance tesing
When the customer supplies te...
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.
Bugs
Emburys's Law
Software has bugs in - we j...
Applies to all non-trivial(>10k lines) projects
Some components of SW will be bug-free
for exampletranslations from one format to another
Kinds of bugs
Causes crashes/freezes
Fail to provide functionally the user needs
Failure to conform non-function requirements
Inappropriate UI design
Documentation/training bugs
Requirement bugs
(opinional)
Help against bugs
Testing
Code review
Refactoring
Change code without c...
If it isn't working properly, refactor.
"Refactor whenever and where possible"
Split classes, move methods, replace algo's etc
Frequent contact with users and stakeholders
Risk-driven development
Experience
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
User Interface
Usability Dimensions
EfficiencySatisfactionEffectiveness
Basics
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
When
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
WIMPS
Windows; Icons; ...
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
Principles
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
Error prevention
Recognition rather than recall
Flexibility and efficiency of use
Aesthetic and minimalist design
recognize, diagnose and recover from errors
Help and documentation
The Human
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
Evaluation -> System model -> Execution -> Mental ...
The Computer
Very fast
Good memory
Good at long, repetitive task (at which humans are poor)
Rubbish at inference and association
HCI
Human-Comp...
Presentation
How the system renders ...
Observation
What the user notices of...
Articulation
Expression of a user’s ...
Performance
Tthe system’s execution ...
Framework
to help coordinate HCI ...
Ergonomics
Physical aspects of inp...
Dialogue Design
Task articulation and perform...
Rendering State
Presenting system state for e...
Styles
Wizard Interface
backcancelnext (setup progra...
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
Form Fill-in
Application/registratio...
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
Wordexcel etc
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
text!
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
Batch Processing
Automaticpre-scripted interac...
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
Ergonomics of a typical GUI
Mini Modes
Some acceptable modes
Long-term modes modes
e.g. doing word processing as opposed t...
Short term “spring-loaded” modes
eg mouse-click-down; modes which continue while the ...
Alert modes modes
require user to rectify an unusual ...
Modes that emulate a real-life situation that is itself modal
e.g. use of different graphics tools
Modes that change the attributes of something
e.g. boldface and underline modes of text entry
Modes that stop functionality, as in error conditions
There should be a clear indicator of the current mod
eg a pointer whose appearance changes
It should be easy to change modes
e.g. graphics pointer and palette
Learnability
The ease with which ne...
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”
Transferable skills
Recall vs Recognition
Recall commands or recognise wor...
Predictability
What happeneds next?
Consistency
Do the same things in t...
External consistency: Consistency with task
Aids learning through transfer
Ergonomic issues
grouping; frequency; etc
Internal consistency: Arbitrary consistency
When there is no meaning to the mapping or consistency wit...
Reachability
Can the user reach all p...
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?
Turning off the paperclip; etc
Translating Input
Input language translated to t...
Can the input reach the(and only the) necessary states of the system ?
Video remote controls and power buttons
Match task analysis or activity diagrams to use cases and class/collaboration diagrams
Small cost to user, larger cost in implementation
Ease of Evaluation
Performance of task transforms...
Translate state from core to output language
output language: the computer trying to communicate back
Must preserve state attributes in terms of domain concepts
Output language often limited in expressivity
Results of file copy in command system
Video simply limited in size – difficult to see context in documents etc.
Heuristic Evaluation
Simple and natural dialogue
simple means no irrelevant or rarely used inf...
Speak the user's language
use concepts from the user's world; don't...
Minimize user memory load
don't make the user remember things from ...
Be consistent
action sequences learned...
Provide feedback
let users know what effect thei...
Provide clearly marked exits
if users get into part of the system that does...
Provide short cuts
help experienced users avoid le...
Good error messages
let the user know what the problem ...
Prevent errors
whenever you discover an...
30 1