AntiPatterns-Patterns in Software Engineering-Lecture 17 Slides-Computer Engineering, Slides of Software Engineering

Download AntiPatterns-Patterns in Software Engineering-Lecture 17 Slides-Computer Engineering and more Slides Software Engineering in PDF only on Docsity!

Patterns in Software Engineering Lecturer: Raman Ramsin^ Lecture 17^ AntiPatterns

Part 2

1

Sharif University of Technology

Part

Patterns in Software Engineering – Lecture 17

AntiPatterns: ArchitecturalAntiPatterns:

Architectural

„

Stovepipe System/Enterprise:

Subsystems/systems are

integrated in an ad hoc manner using multiple integration strategiesand mechanismsand mechanisms.

„

Cover Your Assets:

Document-driven software processes that

produce less than useful requirements and specifications because theproduce less-than-useful requirements and specifications because theauthors evade making important decisions. V

d

L

k

I

V

d

L

k

I

i^

t

th t

hi hl

„

V

endor Lock

I

n:

V

endor Lock

I

n occurs in systems that are highly

dependent upon proprietary architectures. A

hi

b

I

li

i

h

l^

k

f

hi

ifi

i

„

A

rchitecture by Implication:

the lack of architecture specifications

for a system under development.

2

Sharif University of Technology

Patterns in Software Engineering – Lecture 17

A

ntiPatterns: Architectural –

Stovepipe System/Enterprise

p p

y

p

„

Stovepipe System/Enterprise:

Subsystems/systems are integrated in an

„

Stovepipe

System/Enterprise:

Subsystems/systems

are integrated in an

ad hoc manner using multiple integration strategies and mechanisms.

„

Stovepipe

is a popular term used to describe software systems with ad hoc

Stovepipe

is

a popular term used to describe software systems with ad hoc

architectures.

The key problem in a Stovepipe System is the lack of common subsystemabstractions.

the key problem in a Stovepipe Enterprise is the absence of common multisystemconventionsconventions.

„

Solution:

„

Solution:

Enhance encapsulation and introduce common abstractions through layeredarchitectures.

4

Sharif University of Technology

Patterns in Software Engineering – Lecture 17

A

ntiPatterns: Architectural –

Cover Your Assets

„

Cover Your Assets:

Document-driven software processes often produce

less-than-useful requirements and specifications because the authors evadeless than useful requirements and specifications because the authors evademaking important decisions.

In order to avoid making a mistake, the authors take a safer course andelaborate upon alternatives.

„

Solution:

„

Solution:

Enforce the production of Architecture blueprints: abstractions of informationsystems that facilitate communication of requirements and technical plansb t

th

d d

l

between the users and developers.

„

An architecture blueprint is a small set of diagrams and tables thatcommunicate the operational, technical, and systems architecture of current

p

,^

,^

y

and future extensions to information systems.

„

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

5

Sharif University of Technology

and

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

Patterns in Software Engineering – Lecture 17

A

ntiPatterns: Architectural –

Architecture by Implication

y

p

Architecture by Implication:

the lack of architecture

„

Architecture

by Implication:

the

lack of architecture

specifications for a system under development.

U

ll

th

hit

t

ibl

f

th

j^

t h

i^

ith

U

sually, the architects responsible for the project have experience with previous system construction, and therefore assume that documentationis unnecessary.

Management of risk in follow-on system development is oftenoverlooked due to overconfidence and recent system successes.

„

Solution:

A general architecture definition approach that is tailored to eachapplication system can help identify unique requirements and risk areas.

7

Sharif University of Technology

Patterns in Software Engineering – Lecture 17

A

ntiPatterns: Architectural –

Design By Committee

g

y

„

Design by Committee:

The classic AntiPattern from standards bodies;

„

Design

by Committee:

The

classic AntiPattern from standards bodies;

Creates overly complex architectures that lack coherence.It h

f^

t

d

i ti

th t it i

i f

ibl

f^

f

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

Even if the designs were possible, it would not be possible to test the full designdue to complexity, ambiguities, overconstraint, and other specification defects.

The design would lack conceptual clarity because so many people contributed toit and extended it during its creation.

„

Solution:

Clarification of architectural roles and improved process facilitation can refactorbad meeting processes into highly productive events.

8

Sharif University of Technology

Patterns in Software Engineering – Lecture 17

A

ntiPatterns: Architectural –

Reinvent the Wheel

„

Reinvent the Wheel:

T

he pervasive lack of experience

p

p

transfer between software projects leads to substantialreinvention.

„

“Our problem is unique.”

„

Virtually all systems development is done in isolation of projectsand systems with overlapping functionality.

„

Solution:

Design knowledge buried in legacy assets can be leveraged to reducetime-to-market, cost, and risk.

10

Sharif University of Technology

Patterns in Software Engineering – Lecture 17

A

ntiPatterns: 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 projectpeople’s talents to the detriment of the project.

Programming skill does not equate to skill in defining abstractions. There appearto be two distinct groups involved in software development:

abstractionists

g

p

p

(Architects) and their counterparts the

implementationists.

According to experts, implementationists outnumber abstractionistsapproximately 4 to 1

Thus

unfortunately

abstractionists are often outvoted

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

Primary consequence: software designs with excessive complexity, which makethe system difficult to develop, modify, extend, document, and test.

Software usability and system maintenance are impacted by a failure to useeffective abstraction principles.

S

l^

ti

„

S

olution:^

Identifying and differentiating among distinct development roles, and givingarchitects control over architectural design.

11

Sharif University of Technology

architects

control over architectural design.

Patterns in Software Engineering – Lecture 17

AntiPatterns: Management (Contd.)AntiPatterns:

Management (Contd.)

„

Corncob:

Difficult people frequently obstruct and divert the software

development process.

„

Intellectual Violence:

Intellectual violence occurs when someone who

understands a theory, technology, or buzzword uses this knowledge tointimidate others in a meeting situationintimidate others in a meeting situation.

„

Smoke and Mirrors:

Demonstration systems are important sales tools, but

they are often interpreted by end users as representational of production-they are often interpreted by end users as representational of productionquality capabilities.

„

Project Mismanagement:

Inattention to the management of software

j

g

g

development processes causing directionlessness and other symptoms.

13

Sharif University of Technology

Patterns in Software Engineering – Lecture 17

A

ntiPatterns: 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 andexcessive thrashing of requirements/models.

Developers new to object-oriented methods do too much up-frontanalysis and design, using analysis modeling as an exercise to feel

f

bl

i^

h

bl

d

i

comfortable in the problem domain.

A key indicator of Analysis Paralysis is that the analysis documents nolonger make sense to the domain expertslonger make sense to the domain experts.

„

Solution:

Iterative-incremental development processes that defer detailedanalysis until the knowledge is needed.

14

Sharif University of Technology

Patterns in Software Engineering – Lecture 17

A

ntiPatterns: Management –

Death by Planning

g

y

g

„

Death by Planning:

Excessive planning for software projects leading to

complex schedules that cause downstream problems.

„

Solution:

Deliverable

based planning

supplemented with validation milestones

Deliverable

-based planning, supplemented with validation milestones.

Plans should be reviewed and revised on a weekly basis.

16

Sharif University of Technology

Patterns in Software Engineering – Lecture 17

A

ntiPatterns: Management –

Fear of Success

g

„

Fear of Success:

Often occurs when people and projects are

on the brink of success.

„

Some people begin to worry obsessively about the kinds ofthings that

can go wrong

things that

can go wrong

.

„

Solution:

When project completion is imminent

make a clear declaration of

When

project completion is imminent, make a clear declaration of

success.

17

Sharif University of Technology

Patterns in Software Engineering – Lecture 17

A

ntiPatterns: Management –

Intellectual Violence

g

„

Intellectual Violence:

Intellectual violence occurs when

someone who understands a theory, technology, or buzzworduses this knowledge to intimidate others in a meeting situation.

„

Solution:

„

Solution:

Encourage education and practice mentoring throughout theorganizationorganization.

19

Sharif University of Technology

Patterns in Software Engineering – Lecture 17

A

ntiPatterns: Management –

Smoke and Mirrors

g

„

Smoke and Mirrors:

Demonstration systems are important

y

p

sales tools, but they are often interpreted by end users asrepresentational of production-quality capabilities.

„

Solution:

„

Solution:

Practice proper ethics to manage expectations, risk, liabilities, andconsequences in computing sales and marketing situationsconsequences in computing sales and marketing situations.

20

Sharif University of Technology