Transcript DT228/3 - The Institute of Finance Management (IFM)

DT228/3
Software and Knowledge
Engineering
Lecturer: Deirdre Lawless
Traditional Systems
Development




What are the phases ?
What roles are there ?
Who does what ?
What are the difficulties ?
Software/Systems
Development/Engineering

Methodology ?







What is a methodology?
How did it start ?
Why use one ?
Types of methodology ?
What methodologies are you familiar with ?
Key aspects of methodologies ?
Problems of methodologies ?
Early Methodology Era





The SDLC (Waterfall) model
Methodology :”…a recommended collection of
philosophies, phases, rules, procedures,
techniques, tools and training for developers of
information systems”
Well tried and tested
Reduces likelihood of unexpected cost/time
blowouts
Ensures continuity of standards
Methodology Era


Alternative “methodologies” emphasise different
approaches to documentation, data, human, or
process aspects
Packaged product which may include:






Manuals
Education and training
Consultancy support
CASE tools
Pro-forma documents
Model-building templates
Aims of Methodologies

Aims
 A better end product
 A better development process
 A standardised process
 Easier maintenance and enhancement

Categories
 Structured
 Data oriented
 Strategic
 Participative
 Prototyping
 Object-oriented
 Tools
 Systems
Methodology “Backlash”









Productivity failure
Complexity
‘Gilding the lily’
Skills
Tools
Not contingent
One-dimensional
Goal-displacement
No improvements
Criticisms of Methodologies




Structured decomposition is simplistic
approach failing to identify linkages between
systems
Data analysis may not solve business
problems
Participation can be inefficient
Prototyping “makes poor systems palatable”
Why Agile methods?



IT is seen to overpromise and underdeliver
Organizations need quality working software
even though they face constant change
Agile methods stress quality in design

still plan – but understand the limits of planning
What is agility?



Quickness – act rapidly
Lightness – do the minimum needed
Nimbleness – adapt to change
Agile Manifesto
www.agilemanifesto.org
Agile (lightweight)
Methodologies





Reaction to bureaucracy of large rigourous methodologies
Attempt to provide “just enough process to provide a reasonable
payoff”
Agile methods are adaptive rather than predictive
Agile methods are people-oriented rather than process-oriented
“Agile methods derive much of their agility by relying on the tacit
knowledge embodied in the team, rather than writing the
knowledge down in plans”

Barry Boehm
The Agile attitude focuses on:
1. Talent & Skill
(fewer better people)
2. Proximity
(developers - developers - users)
3. Communication
(morale, daily standup)
4. Just-in-time requirements and design
5. Frequent Delivery (incremental development)
6. Reflection
7. Less paper, more tacit / verbal communication
8. Tools
9. Quality in work
10. Different strategies for different projects
Agile Methodologies










Methodologies share common principles, but differ
in practices
eXtreme Programming (XP)
Scrum
Evolutionary Project Management (Evo)
Unified Process (UP)
Crystal
Lean Development (LD)
Adaptive Software Development (ASD)
Dynamic System Development Method (DSDM)
Feature Driven Development (FDD)
Agile Development Process







Agile Development Process
 Iterative and evolutionary development
Timeboxing
 –Set amount of time for iteration
 –Adapt future iteration based on the realities
Adaptive planning
Incremental delivery
Agility
More focused on success than sticking with a plan
Working software is valued and considered measure
of progress
Agile Principles


Highest priority is to satisfy the
customer through early and continuous
delivery of valuable software.
Welcome changing requirements, even
late in development.






Deliver working software frequently


Harness change for the customer's
competitive advantage.

from a couple of weeks to a couple of
months
with a preference to the shorter
timescale.
Business people and developers must
work together daily throughout the
project.
Build projects around motivated
individuals.

Give them the environment and
support they need, and trust them to
get the job done.
Most efficient and effective method of
conveying information to and within a
development team is face-to-face
conversation.
Working software is the primary measure
of progress.
Promote sustainable development.



Continuous attention to technical
excellence and good design enhances
agility.
Simplicity is essential.



Sponsors, developers, and users should
be able to maintain a constant pace
indefinitely.
the art of maximizing the amount of work
not done
The best architectures, requirements,
and designs emerge from self-organizing
teams.
At regular intervals, the team reflects on
how to become more effective, then
tunes and adjusts its behavior
accordingly.
Extreme Programming in a
Nutshell

Extreme Programming:




Style:







Lightweight: little documentation or administration overhead
Agile: able to adapt quickly to changes in user requirements
Best for small scale projects with uncertain or evolving requirements
Iterative development (about a dozen iterations of 1-3 weeks each) of a
complete system on each iteration
Just in time planning (does not plan much beyond the current iteration)
Emphasis on testing (unit tests are written before functionality)
Carefully considers people issues (stand-up meetings, pair programming, no
overtime)
http://www.extremeprogramming.org
Started by Kent Beck at DaimlerChrysler in 1996
But there is still not enough evidence to determine if XP is the ‘holy
grail’ of SE
Essence of XP

Four variables in software development :


Four Values


Communication, Simplicity, Feedback, and Courage
Five Principles


Cost, Time, Quality, Scope
Provide feedback, assume simplicity, make incremental
changes, embrace change, quality work
12 Practices (or fewer)

Planning game, small releases, simple designs, automated
testing, continuous integration, refactoring, pair programming,
collective ownership, 40-hour week, on-site customer, coding
standard, metaphor