Software Development Methodologies Lecturer: Raman Ramsin Lecture - - PowerPoint PPT Presentation

Software Development Methodologies

Lecturer: Raman Ramsin Lecture 18: Process AntiPatterns

Department of Computer Engineering

1

Sharif University of Technology

Software Development Methodologies – Lecture 18

AntiPatterns AntiPatterns

Compiled and presented by Brown et al in 1998 Compiled and presented by Brown et al. in 1998. "An AntiPattern describes a commonly occurring solution to a

• An AntiPattern describes a commonly occurring solution to a

problem that generates decidedly negative consequences."

The AntiPattern may be the result of a manager or developer:

not knowing any better, not having sufficient knowledge or experience in solving a particular

type of problem, or f

having applied a perfectly good pattern in the wrong context.

Department of Computer Engineering

2

Sharif University of Technology

Software Development Methodologies – Lecture 18

AntiPatterns: Viewpoints AntiPatterns: Viewpoints

AntiPatterns are presented from three perspectives – developer, AntiPatterns are presented from three perspectives

developer, architect, and manager:

D

l t A tiP tt

i t h i l bl d

Development AntiPatterns: comprise technical problems and

solutions that are encountered by programmers. f

Architectural AntiPatterns: identify and resolve common problems

in how systems are structured.

Managerial AntiPatterns: address common problems in software

processes and development organizations.

Process Antipatterns deal with common problems in engineering

• r enacting a development process, and can belong to any of the

above viewpoints.

Department of Computer Engineering

3

Sharif University of Technology

above viewpoints.

Software Development Methodologies – Lecture 18

Process AntiPatterns: Development Process AntiPatterns: Development

Lava Flow: Dead code and forgotten design information is frozen in an

ever-changing design.

Ambiguous Viewpoint: Object-oriented analysis and design models

presented without clarifying the viewpoint represented by the model.

Golden Hammer: A familiar technology or concept applied obsessively to

many software problems.

W lki h h Mi fi ld U i

d ’ f h l i

Walking through a Minefield: Using today’s software technology is

analogous to walking through a high-tech mine field: bugs abound.

M h M t K

i t d l i l t d f th

Mushroom Management: Keeping system developers isolated from the

system’s end users.

Department of Computer Engineering

4

Sharif University of Technology

Software Development Methodologies – Lecture 18

Process AntiPatterns: Development – Lava Flow p

Lava Flow: Dead code and forgotten design information is frozen in an ever-

changing design.

Causes:

• R&D code placed into production without configuration management.

p p g g

• Uncontrolled distribution of unfinished code.
• Implementation of several trial approaches for implementing a function.
• Single developer (lone wolf) design or written code
• Single-developer (lone wolf) design or written code.
• Lack of configuration management or process management policies.
• Lack of architecture, or non-architecture-driven development.
• Repetitive development process.
• Architectural scars: Architectural mistakes not removed.

To solve: include a configuration management process that eliminates dead code

and evolves or refactors design toward increasing quality.

To avoid: ensure that sound architecture precedes code development. Department of Computer Engineering

5

Sharif University of Technology

p p

Software Development Methodologies – Lecture 18

Process AntiPatterns: Development – Ambiguous Viewpoint p

g p

Ambiguous Viewpoint: Object-oriented analysis and design (OOA&D)

guous e po

Objec o e ed a a ys s a d des g (OO & ) models that are presented without clarifying the viewpoint represented by the model.

There are three fundamental viewpoints for OOA&D models:

Business viewpoint (Problem-Domain/Conceptual/Essential) Specification viewpoint (System) I mplementation viewpoint (Software/Design)

p

p ( / g )

By default, OOA&D models denote an implementation viewpoint that is

potentially the least useful. Mixed viewpoints don’t allow the fundamental separation of interfaces from implementation details.

Solution: Separate Viewpoints explicitly.

Department of Computer Engineering

6

Sharif University of Technology

Software Development Methodologies – Lecture 18

Process AntiPatterns: Development – Golden Hammer p ld

ld f l h l

Golden Hammer: A Golden Hammer is a familiar technology

• r concept applied obsessively to many software problems.

"When your only tool is a hammer, everything else is a nail." Solution: Solution: expanding the knowledge of developers through education,

t i i d b k t d t d l t training, and book study groups to expose developers to alternative technologies and approaches.

Department of Computer Engineering

7

Sharif University of Technology

Software Development Methodologies – Lecture 18

Process AntiPatterns: Development – Walking through a Minefield p

g g

Walking through a Minefield: Using today’s software technology is

analogous to walking through a high-tech mine field: Numerous bugs are found in released software products are found in released software products.

Solution:

Proper investment in software testing is required to make systems

relatively bug-free. In some progressive companies, the size of testing staff exceeds programming staff staff exceeds programming staff.

The most important change to make to testing procedures is

configuration control of test cases. configuration control of test cases.

automation of test execution and test design.

Department of Computer Engineering

8

Sharif University of Technology

Software Development Methodologies – Lecture 18

Process AntiPatterns: Development – Mushroom Management p

g

Mushroom Management: In some architecture and management circles,

us

• a age

e

so e a c ec u e a d a age e c c es, there is an explicit policy to keep system developers isolated from the system’s end users.

Requirements are passed second-hand through intermediaries, including

architects, managers, or requirements analysts.

Motto: “Keep your developers in the dark and feed them fertilizer ” Motto: Keep your developers in the dark and feed them fertilizer. Mushroom Management assumes that requirements are well understood by

both end users and the software project at project inception. It is assumed both end users and the software project at project inception. It is assumed that requirements are stable.

Solution:

• Risk-driven development: spiral development process based upon prototyping

and user feedback.

Department of Computer Engineering

9

Sharif University of Technology

Software Development Methodologies – Lecture 18

Process AntiPatterns: Architectural Process AntiPatterns: Architectural

Cover Your Assets: Document-driven software processes that Cover Your Assets: Document driven software processes that

produce less-than-useful requirements and specifications because the authors evade making important decisions.

hi b li i

h l k f h f

Architecture by I mplication: the lack of architecture specifications

for a system under development.

Design by Committee: Design by Committee creates overly Design by Committee: Design by Committee creates overly

complex architectures that lack coherence.

Reinvent the Wheel: The pervasive lack of experience transfer Reinvent the Wheel: The pervasive lack of experience transfer

between software projects leads to substantial reinvention.

The Grand Old Duke of York: Egalitarian software processes often

g p ignore people’s talents to the detriment of the project: We need abstractionists as well as implementationists.

Department of Computer Engineering

10

Sharif University of Technology

Software Development Methodologies – Lecture 18

Process AntiPatterns: Architectural – Cover Your Assets

Cover Your Assets: Document-driven software processes often produce

less than useful requirements and specifications because the authors evade less-than-useful requirements and specifications because the authors evade making important decisions.

• In order to avoid making a mistake, the authors take a safer course and

l b t lt ti elaborate upon alternatives.

Solution:

• Enforce the production of Architecture blueprints: abstractions of information

systems that facilitate communication of requirements and technical plans between the users and developers. p

An architecture blueprint is a small set of diagrams and tables that

communicate the operational, technical, and systems architecture of current and future extensions to information systems. y

A typical blueprint comprises no more than a dozen diagrams and tables,

and can be presented in an hour or less as a viewgraph presentation.

Department of Computer Engineering

11

Sharif University of Technology

Software Development Methodologies – Lecture 18

Process AntiPatterns: Architectural – Architecture by Implication

y p

Architecture by I mplication: the lack of architecture Architecture by I mplication: the lack of architecture

specifications for a system under development.

Usually the architects responsible for the project have experience with Usually, the architects responsible for the project have experience with

previous system construction, and therefore assume that documentation is unnecessary.

Management of risk in follow-on system development is often

• verlooked due to overconfidence and recent system successes.

Solution:

A general architecture definition approach that is tailored to each

application system can help identify unique requirements and risk areas.

Department of Computer Engineering

12

Sharif University of Technology

Software Development Methodologies – Lecture 18

Process AntiPatterns: Architectural – Design By Committee

g y

Design by Committee: The classic AntiPattern from standards bodies,

g y

, Design by Committee creates overly complex architectures that lack coherence:

• A complex software design that is the product of a committee process
• A complex software design that is the product of a committee process.
• It has so many features and variations that it is infeasible for any group of

developers to realize the specifications in a reasonable time frame.

• Even if the designs were possible, it would not be possible to test the full design

due to excessive complexity, ambiguities, overconstraint, and other specification defects.

• The design would lack conceptual clarity because so many people contributed to

it and extended it during its creation.

Solution:

Solution:

• Clarification of architectural roles and improved process facilitation can refactor

bad meeting processes into highly productive events.

Department of Computer Engineering

13

Sharif University of Technology

Software Development Methodologies – Lecture 18

Process AntiPatterns: Architectural – Reinvent the Wheel R i t th Wh l Th

i l k f i

Reinvent the Wheel: The pervasive lack of experience

transfer between software projects leads to substantial reinvention.

“Our problem is unique.” Virtually all systems development is done in isolation of projects

and systems with overlapping functionality.

Solution:

Design knowledge buried in legacy assets can be leveraged to reduce

time-to-market, cost, and risk.

Department of Computer Engineering

14

Sharif University of Technology

Software Development Methodologies – Lecture 18

Process AntiPatterns: Architectural – Grand Old Duke of York

The Grand Old Duke of York: Egalitarian software processes often ignore

people’s talents to the detriment of the project people s talents to the detriment of the project.

• Programming skill does not equate to skill in defining abstractions. There appear

to be two distinct groups involved in software development: abstractionists (Architects) and their counterparts the implementationists (Architects) and their counterparts the implementationists.

• According to experts, implementationists outnumber abstractionists

approximately 4 to 1. Thus, unfortunately, abstractionists are often outvoted.

• Primary consequence: software designs with excessive complexity, which make

the system difficult to develop, modify, extend, document, and test.

• Software usability and system maintenance are impacted by a failure to use
• Software usability and system maintenance are impacted by a failure to use

effective abstraction principles.

Solution:

• Identifying and differentiating among distinct development roles, and giving

architects control over architectural design.

Department of Computer Engineering

15

Sharif University of Technology

Software Development Methodologies – Lecture 18

Process AntiPatterns: Management Process AntiPatterns: Management

Analysis Paralysis: Striving for perfection and completeness

in the analysis phase leading to project gridlock and excessive work on requirements/models work on requirements/models.

Death by Planning: Excessive planning for software projects

leading to complex schedules that cause downstream problems leading to complex schedules that cause downstream problems.

Project Mismanagement: Inattention to the management of

software development processes causing directionlessness and software development processes causing directionlessness and

• ther symptoms. Proper monitoring and control of software

projects is necessary.

Department of Computer Engineering

16

Sharif University of Technology

Software Development Methodologies – Lecture 18

Process AntiPatterns: Management – Analysis Paralysis g

y y

Analysis Paralysis: Striving for perfection and completeness

Analysis Paralysis: Striving for perfection and completeness

in the analysis phase often leads to project gridlock and excessive thrashing of requirements/models.

Developers new to object-oriented methods do too much up-

front analysis and design, using analysis modeling as an exercise to feel comfortable in the problem domain exercise to feel comfortable in the problem domain.

A key indicator of Analysis Paralysis is that the analysis

documents no longer make sense to the domain experts documents no longer make sense to the domain experts.

Solution:

Iterative-incremental development processes that defer detailed

analysis until the knowledge is needed.

Department of Computer Engineering

17

Sharif University of Technology

Software Development Methodologies – Lecture 18

Process AntiPatterns: Management – Death by Planning g

y g

Death by Planning: Excessive planning for software projects leading to

complex schedules that cause downstream problems complex schedules that cause downstream problems.

l i

Solution: Deliverable-based planning, supplemented with validation milestones.

Plans should be reviewed and revised on a weekly basis Plans should be reviewed and revised on a weekly basis.

Department of Computer Engineering

18

Sharif University of Technology

Software Development Methodologies – Lecture 18

Process AntiPatterns: Management – Project Mismanagement g

j g

Project Mismanagement: Inattention to the management of Project Mismanagement: Inattention to the management of

software development processes can cause directionlessness and

• ther symptoms.

Proper monitoring and control of software projects is necessary for

successful development activities. Oft k ti iti l k d i i i d Th i l d

Often, key activities are overlooked or minimized. These include

technical planning (architecture) and quality-control activities (inspection and test).

Solution:

Proper risk management incorporated in the project management

process.

Department of Computer Engineering

19

Sharif University of Technology

Software Development Methodologies – Lecture 18

Reference

Brown, W. J., Malveau, R. C., McCormick, H., Mowbray, T.,

Antipatterns: Refactoring Software, Architectures, and P j t i C i i Wil 1998 Projects in Crisis. Wiley, 1998.

Department of Computer Engineering

20

Sharif University of Technology