Tietojärjestelmien peruskurssi
Software engineering
Malin Brännback
Software Engineering
Use of sound engineering principles
good management practice
applicable tools and methods for SD
Before it was more like ad-hoc
SE
More disciplined approach to programming
increase time devoted to program design
increase productivity through savings in
testing and maintenance
gooddesign, good documentation, and
general control of the project
IRACI
Begin with the idea
where do ideas come from?
Don’t ask what should this screen look like or What
should this system do?
Turn them into: What can we do to increase sales?
How can we improve productivity of our sales
force? How can the user best work with this
information?
Instead of how can this be done better? Ask how can
this be done worse!
Idea
Be illogical
try something different - instead of technical
journals; try a toy catalogue
visualise the process
form a mental model, walk through the model,
diagram the problem on paper
The examples: imagine you are the kid playing the
game; contact management system; imagine you
are the sales person
Idea
Break the bounds - why is there a Save
button?
Talk to someone
Brainstorm
Relax
Formalise and evaluate
Formalise and evaluate
Does it make sense?
Does it fit with the Enterprise-wide or
marketing goals
What risks are involved
What benefits are provided
What are the projected costs
Which idea is best
Establish the Requirements
= conceptual design
goal-centred instead of user-centred
create the project team
Creating the Project team
The entire definition and direction of the
project will come from the project team
significant responsibility
must be carefully selected
teams should include users, because they
know the business - they are domain
experts
Selecting the team members
Too many cooks spoil the broth
too many designers spoil the design
still, when time limits become stressed the
problem is solved with adding manpower,
like dousing a fire with more gasoline,
keep the team small enough to
collaborate effectively
The project team
A full team with full responsibility
Then, a core team to do day-to-day work of
the project
not more than 5-6 persons
If the project is very large, break it down
into smaller pieces with one small team
assigned to each pieces
The full team
Steering and oversight committee; representatives
from all areas that are directly or indirectly
affected
regular meetings, responsible for communicating to their
departments
access to all project documentation
minimally, users and technical staff
ideally; current and present users, managers of these,
support staff, subject matter experts, SW analysts,
designers, developers, SW quality control, technical
writers, technical support staff
Team members and responsibilities
Record keeper;maintains the formal project
documents, requirements specifications, architectural
design documents
Project manager;directs the project, decides when to
bring in specialists, etc.
Decision maker; provides the authority to make final
decisions
“Evangelist”;the domain expert with the vision - keeps
the project in focus
Setting the scope
The scope identifies and limits the business or
functional areas affected by the application -
application domain
how does the AD inter-operate with other products
when defining the AD keep the project goal in
mind. Only those related to the goal should be
included - not something for everyone
Identifying the needs
What the business needs to achieve and
what the user needs to accomplish
task analysis - spend time with the users
Specify quality standards
On top of basic business needs
ease of use
conformity to established user interface conventions
maintainability
reliability
performance
acceptable defect level
compatibility with other systems
Defining the technical and marketing
specifications
Minimal required hardware configurations
Recommended
operating systems
network configuration
language, database
portability, reusability
number of users, volume of data
Defining the technical and marketing
specifications
Security requirements
interface to other systems
current technical standards
time to market
internationalisation
Prioritising the requirements
Quality
schedule
features
Pick two of these. There is a trade-off, e.g.
high quality and tight schedule - trade off
the features list
“you must have the new accounting system installed
by the first quarter”
10 Myths of project planning and
scheduling
We have no time to design the application
we will save time and money if we jump into the
code
stepping into a train without having time to travel!
Scheduling is for the birds
toplan for a certain amount of time
make sure there is room in the plan
10 Myths of project planning and
scheduling
Estimates are certain
estimates are estimates
to help convert numbers on a schedule, define risk
factor
add time based on the risk
make room for changes in the plan
10 Myths..
8 hours = 1 Day
Keep two sets of schedules
Pump up the pressure
there is a difference between “How can I best
implement this?” and “What can I throw together
the fastest
If the project is behind, add programmers
the project falls apart - look at the why and fix the
if
why, Don’t just add resources
10 Myths..
If we leave Chris alone it will get done
is always a Chris who can walk on water; only
there
everybody else is keeping Chris busy for technical
advise
Interim Releases are a waste of time
how “done” are things
We’ll Catch up!