918191ISMM1-UC 752SYSTEMS ANALYSISFall 2019 –.docx

9/18/19
1
ISMM1-UC 752:
SYSTEMS ANALYSIS
Fall 2019 – Lecture 3
Instructor: Dr. Antonios Saravanos
Incremental Model
• Development and delivery of
functionality occurs in increments
• Works well when requirements are
known beforehand
• Projects are broken down into sub-
projects
Source: Project Management for IT-Related Projects (p.
18)
2
9/18/19
2

Incremental Cycle
Incremental Model
9/18/19
3
Iterative Model
• Ideal for situations where not all requirements are
known up front
• Need for development to begin as soon as possible
Source: Project Management for IT-Related Projects (p. 19)
5
Iterative Cycle
9/18/19
4
Iterative Model
Incremental vs. Iterative
• Incremental fundamentally means
add onto. Incremental development
helps you improve your process.

• Iterative fundamentally means re-
do. Iterative development helps you
improve your product.
9/18/19
5
• Is iterative and incremental the
same thing?
Source: http://www.applitude.se/images/inc_vs_ite.png
10
9/18/19
6
Iterative and Incremental Combined
A Simple Software Development Method
• Initial Planning
• Design
• Implementation
• Testing
Source: Making Things Happen: Mastering Project Management

(p. 30)
12
n
9/18/19
7
Alistair Cockburn
• What’s Alistair’s take on Iterative vs. Incremental?
• in incremental development, you do each of those
activities multiple times … that is, you go around the
requirements – design – programming – testing –
integration – delivery cycle multiple times. You
“iterate” through that cycle multiple times. (“iterate” –
get it? sigh…)
• in iterative development, you also do each of those
activities multiple times … you go around the
“iterate” through that cycle multiple times. By Gummy!
Both of those are “iterative” development! WOW!
9/18/19
8

Incremental vs. Iterative (cont’d)
• Of course, the $200,000 question is,
do you repeat the cycle “on the same
part of the system you just got done
with” or “on a new part of the
system”? How you answer that
question yields very different results
on what happens next on your
project.
Roles
• Product Owner (Business)
– Represents the customer
– Controls the product backlog
– Signs off on deliverables
• The Scrum Master
– Ensures scrum values are understood and kept
– Tracks progress and finds ways to overcome obstacles
• The Development Team
– The people actually responsible for delivering the system
– Self-organizing unit
– Members of the team are generalists not specialists
• Cross functional (Each member of the team knows all aspects
of the
product that is being developed)
16

9/18/19
9
The Agile System Development Methodology
17
Manifesto for Agile Software Development
18
9/18/19
10
19
20
9/18/19
11

Principles Behind the Agile Manifesto
Source: http://agilemanifesto.org/principles.html
21
22
9/18/19
12
23
Agile methods
• Dissatisfaction with the overheads involved in design
methods led to the creation of agile methods. These
methods:
– Focus on the code rather than the design;
– Are based on an iterative approach to software development;
– Are intended to deliver working software quickly and evolve
this
quickly to meet changing requirements.
• Agile methods are probably best suited to

small/medium-sized business systems or PC products.
9/18/19
13
Principles of agile methods
Principle Description
Customer involvement The customer should be closely
involved throughout the
development process. Their role is provide and prioritise
new system requirements and to evaluate the iterations of
the system.
Incremental delivery The software is developed in increments
with the customer
specifying the requirements to be included in each
increment.
People not process The skills of the development team should
be recognised
and exploited. The team should be left to develop their
own ways of working without prescriptive processes.
Embrace change Expect the system requirements to change and
design the
system so that it can accommodate these changes.
Maintain simplicity Focus on simplicity in both the software
being developed
and in the development process used. Wherever possible,

actively work to eliminate complexity from the system.
Problems with agile methods
• It can be difficult to keep the interest of customers who
are involved in the process.
• Team members may be unsuited to the intense
involvement that characterizes agile methods.
• Prioritizing changes can be difficult where there are
multiple stakeholders.
• Maintaining simplicity requires extra work.
• Contracts may be a problem as with other approaches to
iterative development.
9/18/19
14
The Paradigm Shift
27
Relationship Between Agile Values, Principles, and Practices
Source: http://i.msdn.microsoft.com/dynimg/IC511953.jpg
28

9/18/19
15
Popular Agile Software Development Frameworks
• Scrum
• Extreme programming (XP)
• Crystal
• Kanban (???)
• Dynamic Systems Development Method (DSDM)
• Feature-Driven Development (FDD)
• Source: Pro Agile .NET Development with Scrum (p. 8-11)
29
Principles of Scrum
• Regularly deliver value
• Adjust process according to results
• Allow business to change their mind when needed
• Allow the development team the time to complete their
commitments to the
business
30
9/18/19
16

Scrum Values
• Commit to the goal
• Focus on completing your commitment
• Be open and share with your team
• Respect your team
• Have the courage to act for the best interests of achieving your
goal
31
Roles
of the
32
9/18/19

17
Scrum Values
• Have the courage to act as necessary
33
Scrum Values
34
9/18/19
18
The Scrum Process Lifecycle
Source: Pro Agile .NET Development with Scrum (p.14)
35
Product Backlog

• An ordered list of desired product functionality
36
9/18/19
19
Sprint
• Scrum is comprised of a series of time blocks called sprints
(timeboxes)
• The goal of a sprint is to deliver working software
• The duration of a sprint is typically two to four weeks in
length
• Sprints are isolated from change and represent a commitment
by both the
business and the developer
37
Sprint Backlog
• A list of tasks to be completed during the sprint
• A subset of the product backlog
38
9/18/19

20
Daily Scrum Meetings
• Team meets daily to touch base
• Meetings are usually short short (15-20 minutes in length)
• Provide an opportunity to discuss what has happened since the
last meeting
• What we will take place next
• Any development obstacles
39
Sprint Review
• A meeting during which the team presents the increment that
has been
built during the sprint
• Time of meeting varies on perspective but can range form
from 2 to 4
hours
40
9/18/19
21
Sprint Retrospective
• Traditionally takes place after the sprint review
• Provides an opportunity to go over the sprint and reflect on
activities

• Provides an opportunity to think about what the team should:
– start doing
– stop doing
– continue doing
• The meeting should be comprised of the:
– (entire) development team
– scrum master
– product owner
– Sprint retrospectives usually last for about an hour but
duration varies
according to need
41
1
ISMM1-UC 752:
SYSTEMS ANALYSIS
Fall 2019 – Lecture 4
1
Dilbert Cartoon – Failure
• https://www.youtube.com/watch?v=huEpQj5FcGI
2

2
2
The Agile System Development Methodology
3
3
4
4
3
5
5
6

6
4
7
7
8
8
5
9
9
The Paradigm Shift

10
10
6
Relationship Between Agile Values, Principles, and Practices
Source: http://i.msdn.microsoft.com/dynimg/IC511953.jpg
11
11
Popular Agile Software Development Frameworks
• Scrum
• Extreme programming (XP)
• Crystal
• Dynamic Systems Development Method (DSDM)
• Feature-Driven Development (FDD)
• Source: Pro Agile .NET Development with Scrum (p. 8-11)
12
12
7
Principles of Scrum

• Regularly deliver value
• Adjust process according to results
• Allow business to change their mind when needed
• Allow the development team the time to complete their
commitments to the
business
13
13
Scrum Values
• Have the courage to act for the best interests of achieving your
goal
14
14
8
Roles

of the
15
15
Scrum Values
16
16
9
The Scrum Process Lifecycle
Source: Pro Agile .NET Development with Scrum (p.14)

17
17
Product Backlog
• An ordered list of desired product functionality
18
18
10
Sprint
• Scrum is comprised of a series of time blocks called sprints
(timeboxes)
• The goal of a sprint is to deliver working software
• The duration of a sprint is typically two to four weeks in
length
• Sprints are isolated from change and represent a commitment
by both the
business and the developer
19
19
Sprint Backlog
• A list of tasks to be completed during the sprint

• A subset of the product backlog
20
20
11
Daily Scrum Meetings
• Team meets daily to touch base
• Meetings are usually short short (15-20 minutes in length)
• Provide an opportunity to discuss what has happened since the
last meeting
• What we will take place next
• Any development obstacles
21
21
Sprint Review
• A meeting during which the team presents the increment that
has been
built during the sprint
• Time of meeting varies on perspective but can range form
from 2 to 4
hours
22
22

12
Sprint Retrospective
• Traditionally takes place after the sprint review
• Provides an opportunity to go over the sprint and reflect on
activities
• Provides an opportunity to think about what the team should:
– start doing
– stop doing
– continue doing
• The meeting should be comprised of the:
– (entire) development team
– scrum master
– product owner
– Sprint retrospectives usually last for about an hour but
duration varies
according to need
23
23
Requirements with Agile
24
24

13
User Stories
25
25
•
http://www.thoughtworks.com/products/docs/mingle/13.4/help/e
xplore_mingle_topic_whats_a_card.html
26
26
14
User Stories
• A short description of user-valued function
• Traditionally hand written on a green index card
• Written by the business
• Regarded as a “promise” to discuss
• There is usually a cost estimate attached in points on the
bottom right
corner
• Acceptance test is written on the reverse of the card
• Not static but rather updated during the development process
• Traditionally ripped-up after they have been implemented
• Note that user stories are not:

– use-cases
– scenarios
• Also note that user stories do not meet IEEE 830 Specification
Requirements
27
27
Creating Stories
• The business writes the story
• The developer estimates a cost
• The business prioritizes the stories
• Capacity determines how many stories will be completed in
the next
iteration
• Stories are decomposed into tasks by the development team
• Business and developer meet to discover details which are
captured as the
acceptance test
• Stories should have the following characteristics:
– Independent from other stories
– Negotiable
– Valuable
– Estimable
– Small and Testable
28
28

15
Be Independent from Other Stories
• Stories must be independent of other ones to ensure
• Decompose stories into smaller ones if needed
29
29
Negotiable
• The story is an opportunity for a conversation not a contract
• You should record any questions that need to be asked
30
30
16
Valuable
• The story holds a value to the users of your system
• Technical perspectives should be framed in a way that shows
user value
31
31

Estimable
• If developers cannot place an estimate to a user story then
some thought
should be placed why this is the case.
• Do the developers lack the knowledge to develop such a story
• Is the story so large (“epic”) that it needs to be broken down
into smaller
stories
32
32
17
Estimable
some thought
• Is the story so large (“epic”) that it needs to be broken down
into smaller
stories
• Are there any benefits of epic stories?
33
33

Estimable
some thought
• Is the story so large (“epic”) that you can’t really accurately
estimate its
completion it needs to be broken down into smaller stories
• Are there any benefits of epic stories?
– They can give you a big picture of what is coming in the near
future
34
34
18
Small and Testable
• If a story is epic then it needs to be broken down into smaller
more
manageable stories.
• It should be possible to create an automated test case for each
story
• The test case for each story should be run easily and often
35

35
How to write stories
• You can collect stories using elicitation techniques such as:
– User interviews
– Questionnaires
– Observation
– Focus groups
– Collaborative workshops
• Then use goal driven analysis techniques to help focus the
elicitation
– Start by creating a list of user roles
• Its okay to write epic stories as they can give you an
understanding of the
landscape, just remember they will need to be broken down
• Don’t focus on the UI details when creating the stories
• Don’t order the stories while your creating them
36
36
19
User Story Template
• As a ...
• I want ...
• So that ...

• Source: http://www.andrewfuqua.com/2011/02/scrum-
fundamental-user-stories.html
37
37
Acceptance Criteria Template
• Acceptance criteria defines the conditions of acceptance
– Knowing when we are done
• Provides the developer a set of conditions that must be
finished before the
user story can be considered completed.
• Given ...
• When ...
• Then ...
38
38
20
So the user story card who appear…
• Source: http://blogs.kent.ac.uk/agile/files/2009/09/Slide1-
264x300.jpg
39

39
• http://www.agilemodeling.com/artifacts/userStory.htm
40
40
21
• http://www.agilemodeling.com/artifacts/userStory.htm
41
41
Why use user stories?
• All us to focus at the precise needs of the business
• They are understood by the business (remember the business
writes the
stories and the developer estimates cost)
• They are lightweight
– easy to write
– responsive to change
42
42

22
• Remember agile development is about embracing a set of
values that
underpin the way we work!
• You don’t have to follow a specific framework to be agile!
43
43
Extreme Programming
44
23
XP. The basic problem of software development.
45
Kent Beck
46
24
Martin Fowler. Have we seen one of his products?
47

Extreme programming
• Perhaps the best-known and most widely used
agile method along with Scrum.
• Extreme Programming (XP) takes an ‘extreme’
approach to iterative development.
– New versions may be built several times per day;
– Increments are delivered to customers every 2
weeks;
– All tests must be run for every build and the build is
only accepted if tests run successfully.
48
25
XP Values
• Communication
• Simplicity
• Feedback
• Courage
49
The XP release cycle
50

26
51
52
27
Extreme programming practices 1
Incremental
planning
Requirements are recorded on Story Cards and the Stories
to be included in a release are determined by the time
available and their relative priority. The developers break
these Stories into development ‘Tasks’.
Small Releases The minimal useful set of functionality that
provides
business value is developed first. Releases of the system
are frequent and incrementally add functionality to the first
release.
Simple Design Enough design is carried out to meet the current
requirements and no more.
Test first
development

An automated unit test framework is used to write tests for
a new piece of functionality before that functionality itself
is implemented.
Refactoring All developers are expected to refactor the code
continuously as soon as possible code improvements are
found. This keeps the code simple and maintainable.
53
Extreme programming practices 2
Pair Programming Developers work in pairs, checking each
other’s work and
providing the support to always do a good job.
Collective Ownership The pairs of developers work on all areas
of the system, so
that no islands of expertise develop and all the developers
own all the code. Anyone can change anything.
Continuous
Integration
As soon as work on a task is complete it is integrated into
the whole system. After any such integration, all the unit
tests in the system must pass.
Sustainable pace Large amounts of over-time are not considered
acceptable
as the net effect is often to reduce code quality and
medium term productivity
On-site Customer A representative of the end-user of the system
(the

Customer) should be available full time for the use of the
XP team. In an extreme programming process, the
customer is a member of the development team and is
responsible for bringing system requirements to the team
for implementation.
54
28
XP and agile principles
• Incremental development is supported through small,
frequent system releases.
• Customer involvement means full-time customer
engagement with the team.
• People not process through pair programming, collective
ownership and a process that avoids long working hours.
• Change supported through regular system releases.
• Maintaining simplicity through constant refactoring of
code.
55
Customer involvement
• Customer involvement is a key part of XP where
the customer is part of the development team.

• The role of the customer is:
– To help develop stories that define the requirements
– To help prioritise the features to be implemented in
each release
– To help develop acceptance tests which assess
whether or not the system meets its requirements.
56
29
Requirements scenarios
• In XP, user requirements are expressed as user
stories.
• These are written on cards and the development
team break them down into implementation
tasks. These tasks are the basis of schedule and
cost estimates.
• The customer chooses the stories for inclusion in
the next release based on their priorities and the
schedule estimates.
57
XP and change
• Conventional wisdom in software engineering is to
design for change. It is worth spending time and effort
anticipating changes as this reduces costs later in the life

cycle.
• XP, however, maintains that this is not worthwhile as
changes cannot be reliably anticipated.
• Rather, it proposes constant code improvement
(refactoring) to make changes easier when they have to
be implemented.
58
30
Refactoring
• Refactoring is the process of code improvement where
code is reorganised and rewritten to make it more
efficient, easier to understand, etc.
• Refactoring is required because frequent releases mean
that code is developed incrementally and therefore tends
to become messy.
• Refactoring should not change the functionality of the
system.
• Automated testing simplifies refactoring as you can see if
the changed code still runs the tests successfully.
59
Testing in XP
• Test-first development.

• Incremental test development from scenarios.
• User involvement in test development and
validation.
• Automated test harnesses are used to run all
component tests each time that a new release is
built.
60
31
Test-first development
• Writing tests before code clarifies the
requirements to be implemented.
• Tests are written as programs rather than data
so that they can be executed automatically. The
test includes a check that it has executed
correctly.
• All previous and new tests are automatically run
when new functionality is added. Thus checking
that the new functionality has not introduced
errors.
61
Pair programming
• In XP, programmers work in pairs, sitting together to
develop code.

• This helps develop common ownership of code and
spreads knowledge across the team.
• It serves as an informal review process as each line of
code is looked at by more than 1 person.
• It encourages refactoring as the whole team can benefit
from this.
• Measurements suggest that development productivity
with pair programming is similar to that of two people
working independently.
62
32
Problems with XP
• Customer involvement
– This is perhaps the most difficult problem. It may be
difficult or impossible to find a customer who can
represent all stakeholders and who can be taken off
their normal work to become part of the XP team. For
generic products, there is no ‘customer’ - the
marketing team may not be typical of real customers.
63
Problems with XP
• Architectural design

– The incremental style of development can mean that
inappropriate architectural decisions are made at an early stage
of the process.
– Problems with these may not become clear until many features
have been implemented and refactoring the architecture is very
expensive.
• Test complacency
– It is easy for a team to believe that because it has many tests,
the system is properly tested.
– Because of the automated testing approach, there is a
tendency
to develop tests that are easy to automate rather than tests that
are ‘good’ tests.
64
33
Key points
• Extreme programming includes practices such as
systematic testing, continuous improvement and
customer involvement.
• Customers are involved in developing requirements
which are expressed as simple scenarios.
• The approach to testing in XP is a particular strength
where executable tests are developed before the code is

written.
• Key problems with XP include difficulties of getting
representative customers and problems of architectural
design.
65
XP. The basic problem of software development.
• Schedule slips—the day for delivery comes, and you have to
tell the
customer that the software won't be ready for another six
months.
• Project canceled—after numerous slips, the project is canceled
without ever
going into production.
• System goes sour—the software is successfully put into
production, but
after a couple of years the cost of making changes or the defect
rate rises
so much that the system must be replaced.
• Defect rate—the software is put into production, but the defect
rate is so
high that it isn't used.
• Business misunderstood—the software is put into production,
but it doesn't
solve the business problem that was originally posed.
• Business changes—the software is put into production, but the
business
problem it was designed to solve was replaced six months ago

by another,
more pressing, business problem.
• False feature rich—the software has a host of potentially
interesting
features, all of which were fun to program, but none of which
makes the
customer much money.
• Staff turnover—after two years, all the good programmers on
the project
begin to hate the program and leave.
66
1
ISMM1-UC 752:
SYSTEMS ANALYSIS
Fall 2019
Assigned Reading: The Mythical Man Month
2
2
The Book (1)

1. The Tar Pit
2. The Mythical Man-Month
3. The Surgical Team
4. Aristocracy, Democracy, and System Design
5. The Second-System Effect
6. Passing the Word
7. Why Did the Tower of Babel Fail?
8. Calling the Shot
9. Ten Pounds in a Five-Pound Sack
10. The Documentary Hypothesis
11. Plan to Throw One Away
12. Sharp Tools
The Book (2)
13. The Whole and the Parts
14. Hatching a Catastrophe
15. The Other Face
16. No Silver Bullet – Essence and Accident in
Software Engineering
17. “No Silver Bullet” Refired
18. Propositions of The Mythical Man-Month: True or
False?
19. The Mythical Man-Month after 20 years
20. Fifty Years of Wonder, Excitement and Joy
(Epilogue)
3
The Tar Pit (1)

• Large-system programming is a tar pit in the last
decade.
• The programming systems product:
A Program
A
Programming
Product
A
Programming
System
A
Programming
System Product
The Tar Pit (2)
A Program
A Programming Product:
•can be run, tested,
repaired and extended by
anybody
•general enough
•well documented
A Programming
System:

•collection of
interacting programs
•precisely defined
interfaces between
individual programs
•comply with resource
limitations
•all combinations
tested
A Programming
System Product:
both Programming
System and
Programming
Product
x3
x3
4
The Tar Pit (3)
• The joys of the craft:
– Making things
– Making things that are useful to others
– The fascination of fashioning complex puzzle-like
objects
– Always learning
– Such a tractable medium

• The woes of the craft:
– Adjusting to the requirement of perfection
– Other people tell you what to do
– Worse: must use others’ programs!
The Tar Pit (4)
• The woes of the craft (cont.):
– Bugs!!!
– Bugs get harder as testing progresses
– The product gets obsolete upon or even before
completion
5
The Mythical Man-Month (1)
• Most software projects are late. Why?
– Assumption that all will go well led the schedule plan
– Confuse effort with progress: men and months are NOT
interchangeable!
– Software managers tend to please their managers and
because of uncertainty of programmers’ time estimates,
plan the schedule poorly [as a discipline we lack
estimating data].
– Poor monitoring of project progress
– Natural response to schedule slippage is adding
manpower, which makes matters worse.

• Optimism:
– All programmers are optimists, believing in happy
endings and fairy god-mothers.
– Because programming tasks are usually chained end-to-
end, the probability that each will go well is very small.
• Man-month:
– Cost vary as a product: men · months.
– Progress does not: communication overhead!
– Overhead: intercommunication and training.
6
Different projects types:
Men
M
on
th
s
Perfectly partitionable task
Men
M
on
th

s
Unpartitionable task
Men
M
on
th
s
Partitionable task requiring communicationTask with complex
interrelationships
Men
M
on
th
s
• Proposes a successful rule of thumb:
– 1/3 planning
– 1/6 coding
– 1/4 component test and early system test
– 1/4 system test, all components in hand
• Gutless estimating, or: an omelette example
• Regenerative schedule disaster:
– An example

– Brook’s Law: Adding manpower to a late software
project makes it later.
7
Review
13
Waterfall Model
14
8
Waterfall Model
15
What year did Royce publish his paper on the
Waterfall model?
16
9
Waterfall model?

1970
17
How many steps are there in the Waterfall model?
18
10
7
19
How many times should one go through the
Waterfall process according to Royce?
20
11
2
21

2
Why 2?
22
12
• So what are some other perspectives of Royce’s
the waterfall model?
According to Systems Analysis and Design with UML v2.0
13
Planning Phase
• The planning phase is the fundamental process
of understanding why an information system
should be built and determining how the project
team will go about building it.
Analysis
• The analysis phase answers who will use the
system, what the system will do, and where and
when it will be used. During this phase, the
project team investigates any current system(s),
identifies opportunities for improvement, and
develops a concept for the new system. The
phase has three steps: 1) analysis strategy; 2)

requirements gathering; the development of the
system proposal.
14
Design
• The design phase decides how the system will
operate, in terms of the hardware, software and
network infrastructure; the user interface, forms
and reports; and the specific programs,
databases, and files that will be needed.
Implementation
• The final phase of the SDLC is the
implementation phase, during which the system
is actually built (or purchased, in the case of a
packaged software design). This phase usually
gets the most attention as it is usually the
longest and most expensive phase of the
development process. It is usually comprised of
the following steps: 1) systems construction; 2)
installation; 3) establishment of a support plan.
15
Waterfall Model According to the BCS
• Also known as the once-through
approach

• Best for projects where requirements
are known up front
29
Is Waterfall a Realistic Approach?
• Alistair Cockburn: In waterfall
development, you do “requirements”
only once; then you do “design” only
once; then you do “programming”
only once (ha! ha! fooled you – of
course you do the programming over
and over and over, but don’t tell your
PM that!); you “test” only once (ha!
ha! of course not! – but that’s the
theory); you “integrate” only once;
you “deliver” only once (that part
may be true).
16
Problems with Waterfall Approach
• Feedback ignored, milestones lock in design
specs even when conditions change
• Limited user involvement (only in requirements
phase)
• Too much focus on milestone deadlines of
SDLC phases to the detriment of sound

development practices
Are there other approaches?
What is Frederick Brook’s approach???
17
Frederick Brook’s approach
• Planning
• Coding
• Component Test and Early System Test
• System Test, All Components in Hand
• Planning
• Coding
• Component Test and Early System Test
• System Test, All Components in Hand
Do we know how much time we should invest
on each of these elements?
18
• 1/3 Planning
• 1/6 Coding
• 1/4 Component Test and Early System Test
• 1/4 System Test, All Components in Hand
Well according to our textbook there are three

broad categories…
• Structured
– Waterfall
– Parallel
• RAD
– Phased
– Prototyping
– Throwaway Prototyping
• Agile
– Extreme
19
Parallel Development Methodology
What does Brook’s Think of Parallel?
20
Source: http://home.ubalt.edu/abento/737/projmgt.html
21

Why?
Why?
Communication
E = n(n – I) / 2
22
Well according to our textbook there are three
broad categories…
• Structured
– Waterfall
– Parallel
• RAD
– Phased
– Prototyping
– Throwaway Prototyping
• Agile
– Extreme
Rapid Application Development (RAD)
• Decreases design and implementation
time
• Involves: extensive user involvement,
prototyping, integrated CASE tools, code
generators

• More focus on user interface and system
function, less on detailed business
analysis and system performance
23
Rapid Application Development (RAD) Lifecycle
Phased Development Methodology
24
Prototyping
47
Throwaway Prototyping
48
25
Boehm Spiral Model
Extreme Programming
26

Comparing Methodologies
Quick Exercise
27
Incremental Model
• Development and delivery of
functionality occurs in increments
• Works well when requirements are
known beforehand
• Projects are broken down into sub-
projects
Source: Project Management for IT-Related Projects (p.
18)
53
Incremental Cycle
28
Incremental Model
Iterative Model
• Ideal for situations where not all requirements are
known up front

• Need for development to begin as soon as possible
56
29
Iterative Cycle
Iterative Model
30
• Incremental fundamentally means
add onto. Incremental development
helps you improve your process.
• Iterative fundamentally means re-
do. Iterative development helps you
improve your product.
• Is iterative and incremental the
same thing?
31

61
Iterative and Incremental Combined
32
Alistair Cockburn
• What’s Alistair’s take on Iterative vs. Incremental?
• in incremental development, you do each of those
activities multiple times … that is, you go around the
“iterate” through that cycle multiple times. (“iterate” –
get it? sigh…)
• in iterative development, you also do each of those
activities multiple times … you go around the
“iterate” through that cycle multiple times. By Gummy!
Both of those are “iterative” development! WOW!
33
Incremental vs. Iterative (cont’d)

• Of course, the $200,000 question is,
do you repeat the cycle
• “on the same part of the system you
just got done with” or
• “on a new part of the system”???
How you answer that question
yields very different results on what
happens next on your project.
Quick Exercise
34
Specialization
Computer-aided software engineering (CASE) tools
• CASE tools are productivity tools for
systems analysts that have been
created explicitly to improve their
routine work through the use of
automated support
35
Reasons for Using Case Tools
• Reasons for using CASE tools
– Increasing analyst productivity
– Improving analyst-user communication

– Integrating life cycle activities
Case Tools
• Classic CASE tools - established software development
support tools
(e.g. interactive debuggers, compilers, etc.)
• Real CASE tools - can be separated into three different
categories,
depending on where in the development process they are most
involved in:
– Upper - support analysis and design phases
– Lower - support coding phase
– Integrated - also known as I-CASE support analysis, design
and
coding phases
36
Case Tool Classifications
• Upper CASE tools perform analysis and
design.
• Lower CASE tools generate programs
from CASE design.
Upper CASE Tools
• Create and modify the system design.
• Help in modeling organizational

requirements and defining system
boundaries.
37
Lower CASE Tools
• Lower CASE tools generate computer
source code from the CASE design.
• Source code is usually generated in
several languages.
• Decreases maintenance time
• Generates error-free code
Computer-Aided Software Engineering (CASE) Tools
• Diagramming tools enable graphical
representation.
• Computer displays and report generators help
prototype how systems “look and feel”.
• IBM’s Rational products are the best known
CASE tools.
38
Computer-Aided Software Engineering (CASE) Tools
• Analysis tools automatically check for

consistency in diagrams, forms, and reports.
• A central repository provides integrated storage
of diagrams, reports, and project management
specifications.
Computer-Aided Software Engineering (CASE) Tools (Cont.)
• Documentation generators standardize technical
and user documentation.
• Code generators enable automatic generation of
programs and database code directly from
design documents, diagrams, forms, and
reports.
39
CASE Tools
FIGURE 1-11
Screen shot of
ArgoUML, an open
source CASE tool
(Source:
http://argouml.tigris.org/)
CASE Tools
ISMM1-UC 752:

SYSTEMS ANALYSIS
Fall 2019
Introductions – The Dry and the Wet
10
11
12
13
Systems Analysis: About the Course
Focuses on the concepts and techniques involved in analyzing,
designing, and
documenting the requirements for business information systems.

Topics
include: feasibility, justification, specifications, design,
implementation,
equipment selection, documentation, and performance
evaluation.
15
Course Objectives / Educational Outcomes
Students should upon course completion have a broad
understanding of
system analysis and design methods. By the end of the course
they should be
able to:
• have an understanding of key software process models as well
as their
strengths and weaknesses;
• select and apply appropriate methods and techniques to
generate an
analysis of a situation;
• select and apply appropriate methods and techniques to
generate a system
design for a situation;
• introduce a system design method into an existing
development
environment;
• be familiar with emerging trends in systems analysis and
design.

16
Syllabus
The most up-to-date version of the course syllabus can be found
on NYU
Classes.
17
Required Textbook
???
18
Disclaimer
Most importantly:
– The instructor reserves the right to change this syllabus as
needed. If changes are made a revised syllabus will be uploaded
to
NYU Classes and you will be notified of the version change
through your
@nyu.edu e-mail.
19

Systems Analysis
What is a System?
A group of devices or artificial objects or an organization
forming a
network especially for distributing something or serving a
common
purpose.
Merriam-Webster Dictionary
21
The Mythical Man-Month
• Book by Frederick Brooks published in 1975
• Talks about experiences from managing the development of
the IBM
System / 360 Operating System during the 1960s and early
1970s
– Managed IBM’s System 360 Mainframe
• Brooks tells us that his experience managing the development
of the OS
was a very frustrating but
educational experience
• Programming small vs. large projects
• Likens large projects development to
struggling in a tar pit

Source: Effective Project Management for Smooth Performance
(p. 23)
22
Evolution of the Programming Systems Product
• What is being produced?
– A Program
– A Programming Product
– A Programming System
– A Programming Systems
Product
23
How do we create a system?
Through Processes
24
Process
What is a Process?
A series of actions that produce something or that lead to a
particular

result
Merriam-Webster Dictionary
25
Process
• Can we define the concept of a ‘process’?
– Name some processes to do with software development, in
particular
their triggers and goals/outcomes
• How can we define (‘model’) an individual process?
– What things characterize / are found in / make up a process?
26
Computer Program Development Functions
• According to Royce (1970) there are two essential steps
common to
all computer program developments, regardless of size and
complexity:
– Analysis
– Coding
27
Waterfall Model

28
Waterfall Model
29
Is there a difference between the
Software Development
Lifecycle and the System
Development Lifecycle?
30
Computer Program Development Functions
• According to Royce (1970) there are two essential steps
common to
all computer program developments, regardless of size and
complexity:
– Analysis
– Coding
31
Why should we invest time in systems analysis and design?
32

To minimize the possibility of…
33
To minimize the possibility of… failure!!!
34
Common Factors Leading to the Declaring of Failure
• Cost Overruns
• Time Overruns
• Content Deficiencies
Source: CHAOS Report
35
Waterfall model?
38

Waterfall model?
1970
39
40
7
41
42
2

43
2
Why 2?
44
Systems Analysis
SharePoint and Office 365
Administration and usage
Stavros Zervoudakis
Fall 2019 Guest Lecture
Today’s session – Hands ON
• Environment Overview
• Administration
• Online Apps
• User Management

• Site Setup and Management
• Practice
2019F Guest Lecture - Office 365 and SharePoint:
Administration and Use
Certain images, logos etc. copyright as applicable by their
respective owners.
22
Connect to the platform
Administration and Use 33
• Login https://nyu307.sharepoint.com/sites/Guest/
• ID and Password: to be provided in class You will see:
https://nyu307.sharepoint.com/sites/Guest/
Top left menu to
access
• Apps
• Office 365
• Admin Centers

Overview
Overview
Use your account to connect and as I walk through
the platform, we
- explore
- learn about the architecture
- build sites (intranet, extranet, team site, etc.)
- setup users and access
- install apps
- customize, and
see what is possible with SharePoint and Office 365
Minghuen Tai
System analysis
Prof. Dr. Antonios Saravanos
11/5/2019
Problem statement:
Question 1of 1
Part A:

Imagine you are a software development team that consists of 4
developers, and your client (Fred) has engaged your team to
develop an application in the domain of food. Fred is a little
unsure of the exact nature of the application, but he does know
he needs an initial release in one month (or earlier if at all
possible). You let him know that your team follows an agile
design and planning process and that you will explore the
domain and express your recommended concept via a report.
Please write a report that:
a) Briefly outlines the personas considered and explain why you
decided to focus on one of the personas for this first release.
Hint: you should use the same format used in class: a) For the
brief personas (name + role + picture)
b) For the chosen persona (name + role + picture + quote +
relevant biography)
c) Covers the stories you generated for the chosen persona.
Hint: you should use the same format used in class: a title,
acceptance criteria and an estimate.
d) Covers the release plan, including the goal of each time-box
and what stories will be delivered in that time-box. Your release
plan must include 4 x 1-week time-boxes and must include at
least one release to the public. Please also include your
rationale for deciding the team’s capacity for each time-box,
and why you think that this release plan makes the most sense
for Fred.
Part B:
Please reflect on this experience tying it to the readings that
you have completed so far over the course of the semester.
Expected number of words: 750.
PART A:
Basically, we are a team of four software developers that are
entitled to make a smartphone app for food deliveries by our
client (FRED) who wants to release the app in one month’s
time. Our team specializes in a systematic way of project
management therefore we mostly use one of the techniques of

LEAN design that is Set-Based Concurrent Engineering.
Methodology:
We have our project divided into different design phases that
are as follows:
Step 1: Conceptual Design
Selection of different alternatives or concepts for the market
demands that is:
· Perform a proper survey of the market
· Check the customer preferences for present
· Set the preferences for the basic concept for the project that is
food delivery app
· Select or highlight the different alternatives with respect to
the already set preferences
After the market survey, we get the following preferences;
i. Fast Food
ii. Traditional or Local Specialties
iii. Gourmet Food
We got the percentage of each preference by computing the data
from the market survey and it was 60%, 30% and 10%
respectively.
Step 2: Feasibility Check
After we sent our initial analysis of the market to the client, he
responded with a greenlight on fast food and traditional or local
specialties and asked us to remove the Gourmet food alternative
as it had a very low weightage of the overall survey responses.
Therefore, we removed it from our list of alternatives. But still
the client wanted us to reanalyze the feasibility of the proposed
system and provide a much satisfactory alternative if possible.
Therefore, not only we have to reanalyze the data but also
provide a much better system.
Step 3: Altering the preferences
Since, now-a-days, the trend for fast food is increasing
therefore we give a higher preference to the fast food that is
80% and the remaining 20% goes to the local specialties. In this
way, we have a higher variety of fast food to order and if the
customer wants the local specialties, of course we also have that

in our menu.
Step 4: Finalizing the Conceptual Design
After we sent our alternate design to the client, he approved it
and asked us to provide a proper representation of the process
through more detailed process charts.
Figure 1: METHODOLOGY FOR CONCEPTUAL DESIGN
Current Scenario:
After the conceptual design phase, we move onto the actual
design phase. Here we need to be discrete about our decisions.
Now, we need to specify the preferences that we had selected.
i. Fast Food:
Since fast food is popular these days amongst
the youngsters and the mature people therefore, we have
finalized its selection into our plan.
Figure 2: Fast food
ii. Local Specialties or Traditional Meals:
These are different food types that are specific to
a certain area or a city. For example, there is Biryani from
Karachi, Pakistan and Sajji from Baluchistan, Pakistan and
many more.
Figure 3: local specialty aka Karachi
Biryani
Now we have to provide an acceptance-criteria as to why we
selected the said categories. Since fast food and local
specialties are very popular among the customers of different
ages, different areas and even among the tourists therefore it
was worth it to select these given preferences.
Timeline development:
Now as we are done with the design of the app, we have to

provide the client with a schedule plan for the launch and
implementation of the app.
Week 1:
Following shows the progress and the task that are to be done
during the span of the first week and they are broken down in
phases that are;
· Data gathering and setting preferences
· Filtering the preferences
· Finalizing the conceptual design of the app
Week 2:
Following is a timeline that breaks down the tasks done during
the second week of the app development project. These phases
are as follows;
· Configure and reanalyze the data
· Finalize the preferences
· Start the final development of the app
Week 3:
The following timeline provides the project plan for week 3 and
its different phases through it passes that are as follows;
· The app is developed and ready for trial
· Giving discounts at the local fast food and traditional food
franchises
· Target customers achieved and advertisement is done. The app
is now popular among people.
Figure 6: trial launch of the app
Week 4:
After the successful launch of the app, we need to go through
the errors that we encountered and apply suggestions that the
customers provided after using the app. After this the app is
ready to be launched over a larger span of areas. Following are

the phases that describe the finalized app design report to the
client that is FRED.
· Get the feedback for the trial run of the app
· Make the necessary changes
· Report to client and submit the project report
PART B:
As we have studied that systems engineering revolves around
the engineering fields and evolving around the latest industrial
revolution that is Industry 4.0 and this revolution is moving the
digitization of the customer related services and engineering
industries. Now let us compare our current scenario with the
main concepts of Industry 4.0 and provide analysis for the said
system.
In the end it remains business – with the innovative twist of
innovation and transformation of business models and
processes: increase profit, decrease costs, enhance customer
experience, optimize customer lifetime value and were
possible customer loyalty, sell more and innovate in order to
grow and remain relevant.
· Our system is no doubt the one with innovation and captures
the opportunity of online food delivery
· And since we have everything in our smartphone therefore
there remains no need for calling the franchises for food order,
delivery locations and waiting for the food arrival since it is
integrated with GPS.
· Since it is done through internet therefore there are more
profits with less investments. Also, we get the advertisements
for different products. Therefore, it is a mutual profit situation.
· Customer is satisfied with easy to use interface and services
provided by this app
· There is a feedback system that is directly linked to the
franchises of different restaurants

· The goal of this app is to actively achieve the customer’s
loyalty
· There is always room for new food trends and therefore in
order to survive the competition we have to keep the app
updated for any new type of specialty.
Through the thorough analysis and comparison of the given
situation with advanced tools of digital marketing like Industry
4.0, we can predict that our app will be very popular among the
customers and its users will also enjoy discounts and offers like
friend’s deal, family deal and lovers deal.
So, if I were a consumer, I would definitely give the app a 4.5
rating out of 5 ratings.
ISMM1-UC 752: Systems Analysis
Fall 2019
Take-Home Midterm Examination
Due by midnight on October/29/2019
Guidance:
1. This is an open book examination.
2. Answer all questions.
3. Where material has been quoted or reproduced, you should
take care to identify
the extent of that material, and the source.
4. You may reuse material that was generated and/or submitted
as part of your lab
assignments this semester.

5. If you need to generate any diagrams you should use a
Computer-Aided
Software Engineering (CASE) tool, such as Microsoft Visio.
6. If you need clarification on any of the questions, please
contact the instructor
promptly.
Question 1of 1
Part A
Imagine you are a software development team that consists of 4
developers, and your client (Fred) has
engaged your team to develop an application in the domain of
food. Fred is a little unsure of the exact
nature of the application, but he does know he needs an initial
release in one month (or earlier if at all
possible). You let him know that your team follows an agile
design and planning process and that you will
explore the domain and express your recommended concept via
a report. Please write a report that:
§ Briefly outlines the personas considered and explain why you
decided to focus on one of the
personas for this first release. Hint: you should use the same
format used in class:
a) For the brief personas (name + role + picture)
b) For the chosen persona (name + role + picture + quote +
relevant biography)
§ Covers the stories you generated for the chosen persona. Hint:

you should use the same format
used in class: a title, acceptance criteria and an estimate.
§ Covers the release plan, including the goal of each time-box
and what stories will be delivered in
that time-box. Your release plan must include 4 x 1-week time-
boxes and must include at least one
release to the public. Please also include your rationale for
deciding the team’s capacity for each
time-box, and why you think that this release plan makes the
most sense for Fred.
Part B
Please reflect on this experience tying it to the readings that
you have completed so far over the course of
the semester. Expected number of words: 750.
The Surgical Team
3
The Surgical Team
These studies revealed large individual differences between
high and low performers, often by an order of magnitude.

SACKMAN. ERIKSON, AND GRANT
UPI Photo
29
30 The Surgical Team
At computer society meetings one continually hears young pro-
gramming managers assert that they favor a small, sharp team of
first-class people, rather than a project with hundreds of
program-
mers, and those by implication mediocre. So do we all.
But this naive statement of the alternatives avoids the hard
problem—how does one build large systems on a meaningful
schedule? Let us look at each side of this question in more
detail.
The Problem
Programming managers have long recognized wide productivity
variations between good programmers and poor ones. But the
actual measured magnitudes have astounded all of us. In one of
their studies, Sackman, Erikson, and Grant were measuring
perfor-
mances of a group of experienced programmers. Within just this
group the ratios between best and worst performances averaged
about 10:1 on productivity measurements and an amazing 5:1 on

program speed and space measurements! In short the
$20,000/year
programmer may well be 10 times as productive as the
$10,000/year one. The converse may be true, too. The data
showed no correlation whatsoever between experience and per-
formance. (I doubt if that is universally true.)
I have earlier argued that the sheer number of minds to be
coordinated affects the cost of the effort, for a major part of the
cost is communication and correcting the ill effects of miscom-
munication (system debugging). This, too, suggests that one
wants
the system to be built by as few minds as possible. Indeed, most
experience with large programming systems shows that the
brute-
force approach is costly, slow, inefficient, and produces systems
that are not conceptually integrated. OS/360, Exec 8, Scope
6600,
Multics, TSS, SAGE, etc.—the list goes on and on.
The conclusion is simple: if a 200-man project has 25 manag-
ers who are the most competent and experienced programmers,
fire the 175 troops and put the managers back to programming.
The Problem 31
Now let's examine this solution. On the one hand, it fails to

approach the ideal of the small sharp team, which by common
consensus shouldn't exceed 10 people. It is so large that it will
need
to have at least two levels of management, or about five
managers.
It will additionally need support in finance, personnel, space,
sec-
retaries, and machine operators.
On the other hand, the original 200-man team was not large
enough to build the really large systems by brute-force methods.
Consider OS/360, for example. At the peak over 1000 people
were
working on it—programmers, writers, machine operators,
clerks,
secretaries, managers, support groups, and so on. From 1963
through 1966 probably 5000 man-years went into its design,
con-
struction, and documentation. Our postulated 200-man team
would have taken 25 years to have brought the product to its
present stage, if men and months traded evenly!
This then is the problem with the small, sharp team concept:
it is too slow for really big systems. Consider the OS/360 job as
it
might be tackled with a small, sharp team. Postulate a 10-man
team. As a bound, let them be seven times as productive as
medi-
ocre programmers in both programming and documentation, be-
cause they are sharp. Assume OS/360 was built only by
mediocre
programmers (which is far from the truth). As a bound, assume

that another productivity improvement factor of seven comes
from reduced communication on the part of the smaller team.
Assume the same team stays on the entire job. Well, 5000/(10 X
7X7) = 10; they can do the 5000 man-year job in 10 years. Will
the product be interesting 10 years after its initial design? Or
will
it have been made obsolete by the rapidly developing software
technology?
The dilemma is a cruel one. For efficiency and conceptual
integrity, one prefers a few good minds doing design and
construc-
tion. Yet for large systems one wants a way to bring
considerable
manpower to bear, so that the product can make a timely
appear-
ance. How can these two needs be reconciled?
Mills's Proposal
A proposal by Harlan Mills offers a fresh and creative solu-
tion.^''' Mills proposes that each segment of a large job be
tackled
by a team, but that the team be organized like a surgical team
rather than a hog-butchering team. That is, instead of each
mem-
ber cutting away on the problem, one does the cutting and the
others give him every support that will enhance his
effectiveness

and productivity.
A little thought shows that this concept meets the desiderata,
if it can be made to work. Few minds are involved in design and
construction, yet many hands are brought to bear. Can it work?
Who are the anesthesiologists and nurses on a programming
team,
and how is the work divided? Let me freely mix metaphors to
suggest how such a team might work if enlarged to include all
conceivable support.
The surgeon. Mills calls him a chief programmer. He personally
defines the functional and performance specifications, designs
the
program, codes it, tests it, and writes its documentation. He
writes
in a structured programming language such as PL/I, and has
effec-
tive access to a computing system which not only runs his tests
but
also stores the various versions of his programs, allows easy
file
updating, and provides text editing for his documentation. He
needs great talent, ten years experience, and considerable
systems
and application knowledge, whether in applied mathematics,
business data handling, or whatever.
The copilot. He is the alter ego of the surgeon, able to do any
part of the job, but is less experienced. His main function is to
share in the design as a thinker, discussant, and evaluator. The
surgeon tries ideas on him, but is not bound by his advice. The

copilot often represents his team in discussions of function and
interface with other teams. He knows all the code intimately. He
researches alternative design strategies. He obviously serves as
insurance against disaster to the surgeon. He may even write
code,
but he is not responsible for any part of the code.
Mills's Proposal 33
The administrator. The surgeon is boss, and he must have the
last word on personnel, raises, space, and so on, but he must
spend
almost none of his time on these matters. Thus he needs a
profes-
sional administrator who handles money, people, space, and ma-
chines, and who interfaces with the administrative machinery of
the rest of the organization. Baker suggests that the
administrator
has a full-time job only if the project has substantial legal, con-
tractual, reporting, or financial requirements because of the
user-
producer relationship. Otherwise, one administrator can serve
two
teams.
The editor. The surgeon is responsible for generating the docu-
mentation—for maximum clarity he must write it. This is true of
both external and internal descriptions. The editor, however,
takes
the draft or dictated manuscript produced by the surgeon and

criticizes it, reworks it, provides it with references and
bibliogra-
phy, nurses it through several versions, and oversees the
mechan-
ics of production.
Two secretaries. The administrator and the editor will each need
a secretary; the administrator's secretary will handle project
corre-
spondence and non-product files.
The program clerk. He is responsible for maintaining all the
technical records of the team in a programming-product library.
The clerk is trained as a secretary and has responsibility for
both
machine-readable and human-readable files.
All computer input goes to the clerk, who logs and keys it if
required. The output listings go back to him to be filed and in-
dexed. The most recent runs of any model are kept in a status
notebook; all previous ones are filed in a chronological archive.
Absolutely vital to Mills's concept is the transformation of
programming "from private art to public practice" by making all
the computer runs visible to all team members and identifying
all
programs and data as team property, not private property.
The specialized function of the program clerk relieves pro-
grammers of clerical chores, systematizes and ensures proper
per-

formance of those oft-neglected chores, and enhances the team's
most valuable asset—its work-product. Clearly the concept as
set
forth above assumes batch runs. When interactive terminals are
used, particularly those with no hard-copy output, the program
clerk's functions do not diminish, but they change. Now he logs
all updates of team program copies from private working copies,
still handles all batch runs, and uses his own interactive facility
to
control the integrity and availability of the growing product.
The toolsmith. File-editing, text-editing, and interactive debug-
ging services are now readily available, so that a team will
rarely
need its own machine and machine-operating crew. But these
services must be available with unquestionably satisfactory re-
sponse and reliability; and the surgeon must be sole judge of the
adequacy of the service available to him. He needs a toolsmith,
responsible for ensuring this adequacy of the basic service and
for
constructing, maintaining, and upgrading special tools—mostly
interactive computer services—needed by his team. Each team
will
need its own toolsmith, regardless of the excellence and
reliability
of any centrally provided service, for his job is to see to the
tools
needed or wanted by his surgeon, without regard to any other

team's needs. The tool-builder will often construct specialized
utilities, catalogued procedures, macro libraries.
The tester. The surgeon will need a bank of suitable test cases
for testing pieces of his work as he writes it, and then for
testing
the whole thing. The tester is therefore both an adversary who
devises system test cases from the functional specs, and an
assis-
tant who devises test data for the day-by-day debugging. He
would also plan testing sequences and set up the scaffolding re-
quired for component tests.
The language lawyer. By the time Algol came along, people
began to recognize that most computer installations have one or
two people who delight in mastery of the intricacies of a
program-
ming language. And these experts turn out to be very useful and
very widely consulted. The talent here is rather different from
that
of the surgeon, who is primarily a system designer and who
thinks
How It Works 35
representations. The language lawyer can find a neat and
efficient
way to use the language to do difficult, obscure, or tricky
things.
Often he will need to do small studies (two or three days) on
good

technique. One language lawyer can service two or three
surgeons.
This, then, is how 10 people might contribute in well-
differentiated and specialized roles on a programming team
built
on the surgical model.
How It Works
The team just defined meets the desiderata in several ways. Ten
people, seven of them professionals, are at work on the
problem,
but the system is the product of one mind—or at most two,
acting
uno animo.
Notice in particular the differences between a team of two
programmers conventionally organized and the surgeon-copilot
team. First, in the conventional team the partners divide the
work,
and each is responsible for design and implementation of part of
the work. In the surgical team, the surgeon and copilot are each
cognizant of all of the design and all of the code. This saves the
labor of allocating space, disk accesses, etc. It also ensures the
conceptual integrity of the work.
Second, in the conventional team the partners are equal, and

the inevitable differences of judgment must be talked out or
com-
promised. Since the work and resources are divided, the differ-
ences in judgment are confined to overall strategy and
interfacing,
but they are compounded by differences of interest—e.g., whose
space will be used for a buffer. In the surgical team, there are
no
differences of interest, and differences of judgment are settled
by
the surgeon unilaterally. These two differences—lack of
division
of the problem and the superior-subordinate relationship—make
it possible for the surgical team to act uno animo.
Yet the specialization of function of the remainder of the team
is the key to its efficiency, for it permits a radically simpler
com-
munication pattern among the members, as Fig. 3.1 shows.
I
Secretary
Fig. 3.1 Communication patterns in 10-man programming teams
Baker's article^ reports on a single, small-scale test of the team
concept. It worked as predicted for that case, with
phenomenally
good results.

Scaling Up
So far, so good. The problem, however, is how to build things
that
today take 5000 man-years, not things that take 20 or 30. A 10-
man team can be effective no matter how it is organized, if the
whole job is within its purview. But how is the surgical team
concept to be used on large jobs when several hundred people
are
brought to bear on the task?
The success of the scaling-up process depends upon the fact
that the conceptual integrity of each piece has been radically
im-
proved—that the number of minds determining the design has
Scaling Up 37
been divided by seven. So it is possible to put 200 people on a
problem and face the problem of coordinating only 20 minds,
those of the surgeons.
For that coordination problem, however, separate techniques
must be used, and these are discussed in succeeding chapters.
Let
it suffice here to say that the entire system also must have
concep-
tual integrity, and that requires a system architect to design it
all,

from the top down. To make that job manageable, a sharp
distinc-
tion must be made between architecture and implementation,
and
the system architect must confine himself scrupulously to archi-
tecture. However, such roles and techniques have been shown to
be feasible and, indeed, very productive.
4
Aristocracy, Democracy,
and System Design
tl
Aristocracy, Democracy,
and System Design
This great church is an incomparable work of art. There is
neither aridity nor confusion in the tenets it sets forth. . . .
// is the zenith of a style, the work of artists who had
understood and assimilated all their predecessors ' successes,
in complete possession of the techniques of their times, but

using them without indiscreet display nor gratuitous feats
of skill.
It was Jean d'Orbais who undoubtedly conceived the
general plan of the building, a plan which was respected,
at least in its essential elements, by his successors. This is
one of the reasons for the extreme coherence and unity of
the edifice.
REIMS CATHEDRAL GUIDEBOOK'
Photographies Emmanuel Boudot-Lamotte
41
42 Aristocracy, Democracy, and System Design
Conceptual Integrity
Most European cathedrals show differences in plan or architec-
tural style between parts built in different generations by
different
builders. The later builders were tempted to ''improve'' upon the
designs of the earlier ones, to reflect both changes in fashion
and
differences in individual taste. So the peaceful Norman transept
abuts and contradicts the soaring Gothic nave, and the result
pro-
claims the pridefulness of the builders as much as the glory of

God.
Against these, the architectural unity of Reims stands in glori-
ous contrast. The joy that stirs the beholder comes as much
from
the integrity of the design as from any particular excellences.
As
the guidebook tells, this integrity was achieved by the self-
abne-
gation of eight generations of builders, each of whom sacrificed
some of his ideas so that the whole might be of pure design. The
result proclaims not only the glory of God, but also His power
to
salvage fallen men from their pride.
Even though they have not taken centuries to build, most
programming systems reflect conceptual disunity far worse than
that of cathedrals. Usually this arises not from a serial
succession
of master designers, but from the separation of design into many
tasks done by many men.
I will contend that conceptual integrity is the most important
consideration in system design. It is better to have a system
omit
certain anomalous features and improvements, but to reflect one
set of design ideas, than to have one that contains many good
but
independent and uncoordinated ideas. In this chapter and the
next

two, we will examine the consequences of this theme for
program-
ming system design:
• How is conceptual integrity to be achieved?
• Does not this argument imply an elite, or aristocracy of archi-
tects, and a horde of plebeian implementers whose creative
talents and ideas are suppressed?
Achieving Conceptual Integrity 43
• How does one keep the architects from drifting off into the
blue with unimplementable or costly specifications?
• How does one ensure that every trifling detail of an architec-
tural specification gets communicated to the implementer,
properly understood by him, and accurately incorporated into
the product?
Achieving Conceptual Integrity
The purpose of a programming system is to make a computer
easy
to use. To do this, it furnishes languages and various facilities
that
are in fact programs invoked and controlled by language
features.
But these facilities are bought at a price: the external
description
of a programming system is ten to twenty times as large as the

external description of the computer system itself. The user
finds
it far easier to specify any particular function, but there are far
more to choose from, and far more options and formats to
remem-
ber.
Ease of use is enhanced only if the time gained in functional
specification exceeds the time lost in learning, remembering,
and
searching manuals. With modern programming systems this gain
does exceed the cost, but in recent years the ratio of gain to cost
seems to have fallen as more and more complex functions have
been added. I am haunted by the memory of the ease of use of
the
IBM 650, even without an assembler or any other software at
all.
Because ease of use is the purpose, this ratio of function to
conceptual complexity is the ultimate test of system design.
Nei-
ther function alone nor simplicity alone defines a good design.
This point is widely misunderstood. Operating System/360 is
hailed by its builders as the finest ever built, because it
indisputa-
bly has the most function. Function, and not simplicity, has al-

ways been the measure of excellence for its designers. On the
other hand, the Time-Sharing System for the PDP-10 is hailed
by
its builders as the finest, because of its simpHcity and the
spareness
of its concepts. By any measure, however, its function is not
even
in the same class as that of OS/360. As soon as ease of use is
held
up as the criterion, each of these is seen to be unbalanced,
reaching
for only half of the true goal.
For a given level of function, however, that system is best in
which one can specify things with the most simplicity and
straightforwardness. Simplicity is not enough. Mooers's TRAC
language and Algol 68 achieve simplicity as measured by the
num-
ber of distinct elementary concepts. They are not, however,
straightforward. The expression of the things one wants to do
often
requires involuted and unexpected combinations of the basic
facil-
ities. It is not enough to learn the elements and rules of
combina-
tion; one must also learn the idiomatic usage, a whole lore of
how
the elements are combined in practice. Simplicity and
straightfor-

wardness proceed from conceptual integrity. Every part must re-
flect the same philosophies and the same balancing of
desiderata.
Every part must even use the same techniques in syntax and
analogous notions in semantics. Ease of use, then, dictates unity
of design, conceptual integrity.
Aristocracy and Democracy
Conceptual integrity in turn dictates that the design must
proceed
from one mind, or from a very small number of agreeing
resonant
minds.
Schedule pressures, however, dictate that system building
needs many hands. Two techniques are available for resolving
this
dilemma. The first is a careful division of labor between
architec-
ture and implementation. The second is the new way of structur-
ing programming implementation teams discussed in the
previous
chapter.
The separation of architectural effort from implementation is
a very powerful way of getting conceptual integrity on very
large
projects. I myself have seen it used with great success on IBM's
Stretch computer and on the System/360 computer product line.

Aristocracy and Democracy 45
I have seen it fail through lack of application on Operating Sys-
tem/360.
By the architecture of a system, I mean the complete and de-
tailed specification of the user interface. For a computer this is
the
programming manual. For a compiler it is the language manual.
For
a control program it is the manuals for the language or
languages
used to invoke its functions. For the entire system it is the
union
of the manuals the user must consult to do his entire job.
The architect of a system, like the architect of a building, is
the user's agent. It is his job to bring professional and technical
knowledge to bear in the unalloyed interest of the user, as
opposed
to the interests of the salesman, the fabricator, etc.^
Architecture must be carefully distinguished from implemen-
tation. As Blaauw has said, ''Where architecture tells what hap-
pens, implementation tells how it is made to happen."^ He gives
as a simple example a clock, whose architecture consists of the
face, the hands, and the winding knob. When a child has learned

this architecture, he can tell time as easily from a wristwatch as
from a church tower. The implementation, however, and its real-
ization, describe what goes on inside the case—powering by any
of many mechanisms and accuracy control by any of many.
In System/360, for example, a single computer architecture is
implemented quite differently in each of some nine models.
Con-
versely, a single implementation, the Model 30 data flow,
memory,
and microcode, serves at different times for four different
architec-
tures: a System/360 computer, a multiplex channel with up to
224
logically independent subchannels, a selector channel, and a
1401
computer.*
The same distinction is equally applicable to programming
systems. There is a U.S. standard Fortran IV. This is the
architec-
ture for many compilers. Within this architecture many imple-
mentations are possible: text-in-core or compiler-in-core,
fast-compile or optimizing, syntax-directed or ad-hoc. Likewise
any assembler language or job-control language admits of many
implementations of the assembler or scheduler.

Now we can deal with the deeply emotional question of aris-
tocracy versus democracy. Are not the architects a new
aristocracy,
an intellectual elite, set up to tell the poor dumb implementers
what to do? Has not all the creative work been sequestered for
this
elite, leaving the implementers as cogs in the machine? Won't
one
get a better product by getting the good ideas from all the team,
following a democratic philosophy, rather than by restricting
the
development of specifications to a few?
As to the last question, it is the easiest. I will certainly not
contend that only the architects will have good architectural
ideas.
Often the fresh concept does come from an implementer or from
a user. However, all my own experience convinces me, and I
have
tried to show, that the conceptual integrity of a system
determines
its ease of use. Good features and ideas that do not integrate
with
a system's basic concepts are best left out. If there appear many
such important but incompatible ideas, one scraps the whole
sys-
tem and starts again on an integrated system with different basic
concepts.
As to the aristocracy charge, the answer must be yes and no.

Yes, in the sense that there must be few architects, their product
must endure longer than that of an implementer, and the
architect
sits at the focus of forces which he must ultimately resolve in
the
user's interest. If a system is to have conceptual integrity,
someone
must control the concepts. That is an aristocracy that needs no
apology.
No, because the setting of external specifications is not more
creative work than the designing of implementations. It is just
different creative work. The design of an implementation, given
an
architecture, requires and allows as much design creativity, as
many new ideas, and as much technical brilliance as the design
of
the external specifications. Indeed, the cost-performance ratio
of
the product will depend most heavily on the implementer, just
as
ease of use depends most heavily on the architect.
There are many examples from other arts and crafts that lead
one to believe that discipline is good for art. Indeed, an artist's
What Does the Implementer Do While Waiting? 47

aphorism asserts, 'Torm is liberating/' The worst buildings are
those whose budget was too great for the purposes to be served.
Bach's creative output hardly seems to have been squelched by
the
necessity of producing a limited-form cantata each week. I am
sure
that the Stretch computer would have had a better architecture
had it been more tightly constrained; the constraints imposed by
the System/360 Model 30's budget were in my opinion entirely
beneficial for the Model 75's architecture.
Similarly, I observe that the external provision of an architec-
ture enhances, not cramps, the creative style of an implementing
group. They focus at once on the part of the problem no one has
addressed, and inventions begin to flow. In an unconstrained
im-
plementing group, most thought and debate goes into
architectural
decisions, and implementation proper gets short shrift.^
This effect, which I have seen many times, is confirmed by
R. W. Conway, whose group at Cornell built the PL/C compiler
for the PL/I language. He says, ''We finally decided to
implement
the language unchanged and unimproved, for the debates about
language would have taken all our effort."^
What Does the Implementer Do While Waiting?
It is a very humbling experience to make a multimillion-dollar
mistake, but it is also very memorable. I vividly recall the night

we decided how to organize the actual writing of external
specifi-
cations for OS/360. The manager of architecture, the manager of
control program implementation, and I were threshing out the
plan, schedule, and division of responsibilities.
The architecture manager had 10 good men. He asserted that
they could write the specifications and do it right. It would take
ten months, three more than the schedule allowed.
The control program manager had 150 men. He asserted that
they could prepare the specifications, with the architecture team
coordinating; it would be well-done and practical, and he could
do
it on schedule. Furthermore, if the architecture team did it, his
150
men would sit twiddling their thumbs for ten months.
To this the architecture manager responded that if I gave the
control program team the responsibiUty, the result would not in
fact be on time, but would also be three months late, and of
much
lower quality. I did, and it was. He was right on both counts.
Moreover, the lack of conceptual integrity made the system far
more costly to build and change, and I would estimate that it
added a year to debugging time.
Many factors, of course, entered into that mistaken decision;

but the overwhelming one was schedule time and the appeal of
putting all those 150 implementers to work. It is this siren song
whose deadly hazards I would now make visible.
When it is proposed that a small architecture team in fact
write all the external specifications for a computer or a
program-
ming system, the implementers raise three objections:
• The specifications will be too rich in function and will not
reflect practical cost considerations.
• The architects will get all the creative fun and shut out the
inventiveness of the implementers.
• The many implementers will have to sit idly by while the
specifications come through the narrow funnel that is the
architecture team.
The first of these is a real danger, and it will be treated in the
next chapter. The other two are illusions, pure and simple. As
we
have seen above, implementation is also a creative activity of
the
first order. The opportunity to be creative and inventive in
imple-
mentation is not significantly diminished by working within a
given external specification, and the order of creativity may
even
be enhanced by that discipline. The total product will surely be.
The last objection is one of timing and phasing. A quick an-
swer is to refrain from hiring implementers until the

specifications
are complete. This is what is done when a building is
constructed.
In the computer systems business, however, the pace is
quicker, and one wants to compress the schedule as much as
possible. How much can specification and building be
overlapped?
What Does the Implementer Do While Waiting? 49
As Blaauw points out, the total creative effort involves three
distinct phases: architecture, implementation, and realization. It
turns out that these can in fact be begun in parallel and …
Frederick P. Brooks, Jr.
University of North Carolina at Chapel Hill
Boston • San Francisco * New York « Toronto « Montreal
London « Munich * Paris e Madrid
Capetown • Sydney • Tokyo • Singapore • Mexico City
ADDISON-WESLEY
Cover drawing: C. R. Knight, Mural of the La Brea Tar Pits.
Courtesy
of the George C. Page Museum of La Brea Discoveries, The

Natural
History Museum of Los Angeles County. Cover designer: Diana
Coe.
The essay entitled, No Silver Bullet, is from Information
Processing
1986, the Proceedings of the IFIP Tenth World Computing
Conference,
edited by H.-J. Kugler, 1986, pages 1069-1076. Reprinted with
the kind
permission of IFIP and Elsevier Science B.V., Amsterdam, The
Neth-
erlands.
Library of Congress Cataloging-in-Publication Data
Brooks, Frederick P., Jr. (Frederick Phillips)
The mythical man-month : essays on software engineering /
Frederick P. Brooks, Jr. — Anniversary ed.
p. cm.
Includes bibliographical references and index.
ISBN 0-201-83595-9
1. Software engineering. I. Title.
QA76.758.B75 1995
005.1'068—dc20 94-36653
CIP
Many of the designations used by manufacturers and sellers to
distin-
guish their products are claimed as trademarks. Where those
designa-
tions appear in this book, and Addison-Wesley was aware of a

trademark claim, the designations have been printed in initial
caps or
all caps.
Copyright © 1995 Addison Wesley Longman, Inc.
All rights reserved. No part of this publication may be
reproduced,
stored in a retrieval system, or transmitted in any form or by
any means,
electronic, mechanical, photocopying, recording, or otherwise,
without
prior written permission of the publisher and author. Printed in
the
United States of America.
Text printed on recycled and acid-free paper.
ISBN 0201835959
17 1819202122 MA 05 04 03 02
17th Printing August 2002
Dedication of the 1975 edition
To two who especially enriched my IBM years:
Thomas /. Watson, Jr.,
whose deep concern for people still permeates his company,
and
Bob O. Evans,
whose bold leadership turned work into
Dedication of the 1995 edition

To Nancy,
God's gift to me.
To my surprise and delight, The Mythical Man-Month continues
to be popular after 20 years. Over 250,000 copies are in print.
People often ask which of the opinions and recommendations
set forth in 1975 I still hold, and which have changed, and how.
Whereas I have from time to time addressed that question in
lec-
tures, I have long wanted to essay it in writing.
Peter Gordon, now a Publishing Partner at Addison-Wesley,
has been working with me patiently and helpfully since 1980.
He proposed that we prepare an Anniversary Edition. We de-
cided not to revise the original, but to reprint it untouched (ex-
cept for trivial corrections) and to augment it with more current
thoughts.
Chapter 16 reprints "No Silver Bullet: Essence and Acci-
dents of Software Engineering," a 1986 IFIPS paper that grew
out of my experience chairing a Defense Science Board study on
military software. My coauthors of that study, and our executive
secretary, Robert L. Patrick, were invaluable in bringing me
back into touch with real-world large software projects. The pa-
per was reprinted in 1987 in the IEEE Computer magazine,
which
gave it wide circulation.
"No Silver Bullet" proved provocative. It predicted that a
decade would not see any programming technique that would
by itself bring an order-of-magnitude improvement in software

productivity. The decade has a year to run; my prediction seems
safe. "NSB" has stimulated more and more spirited discussion
V ll
viii Preface to the 20th Anniversary Edition
in the literature than has The Mythical Man-Month. Chapter 17,
therefore, comments on some of the published critique and up-
dates the opinions set forth in 1986.
In preparing my retrospective and update of The Mythical
Man-Month, I was struck by how few of the propositions as-
serted in it have been critiqued, proven, or disproven by on-
going software engineering research and experience. It proved
useful to me now to catalog those propositions in raw form,
stripped of supporting arguments and data. In hopes that these
bald statements will invite arguments and facts to prove, dis-
prove, update, or refine those propositions, I have included this
outline as Chapter 18.
Chapter 19 is the updating essay itself. The reader should
be warned that the new opinions are not nearly so well in-
formed by experience in the trenches as the original book was.
I have been at work in a university, not industry, and on small-
scale projects, not large ones. Since 1986, I have only taught
software engineering, not done research in it at all. My research
has rather been on virtual environments and their applications.
In preparing this retrospective, I have sought the current
views of friends who are indeed at work in software engineer-
ing. For a wonderful willingness to share views, to comment
thoughtfully on drafts, and to re-educate me, I am indebted to
Barry Boehm, Ken Brooks, Dick Case, James Coggins, Tom

DeMarco, Jim McCarthy, David Parnas, Earl Wheeler, and Ed-
ward Yourdon. Fay Ward has superbly handled the technical
production of the new chapters.
I thank Gordon Bell, Bruce Buchanan, Rick Hayes-Roth, my
colleagues on the Defense Science Board Task Force on
Military
Software, and, most especially, David Parnas for their insights
and stimulating ideas for, and Rebekah Bierly for technical pro-
duction of, the paper printed here as Chapter 16. Analyzing the
software problem into the categories of essence and accident
was
inspired by Nancy Greenwood Brooks, who used such analysis
in a paper on Suzuki violin pedagogy.
Preface to the 20th Anniversary Edition ix
Addison-Wesley's house custom did not permit me to ac-
knowledge in the preface to the 1975 edition the key roles
played by their staff. Two persons' contributions should be es-
pecially cited: Norman Stanton, then Executive Editor, and Her-
bert Boes, then Art Director. Boes developed the elegant style,
which one reviewer especially cited: "wide margins, [and] imag-
inative use of typeface and layout." More important, he also
made the crucial recommendation that every chapter have an
opening picture. (I had only the Tar Pit and Reims Cathedral at
the time.) Finding the pictures occasioned an extra year's work
for me, but I am eternally grateful for the counsel.
Soli Deo gloria—To God alone be glory.
Chapel Hill, N.C.. F. P. B., Jr.
March 1995

In many ways, managing a large computer programming proj-
ect is like managing any other large undertaking—in more ways
than most programmers believe. But in many other ways
it is different—in more ways than most professional managers
expect.
The lore of the field is accumulating. There have been sev-
eral conferences, sessions at AFIPS conferences, some books,
and papers. But it is by no means yet in shape for any
systematic
textbook treatment. It seems appropriate, however, to offer this
little book, reflecting essentially a personal view.
Although I originally grew up in the programming side of
computer science, I was involved chiefly in hardware architec-
ture during the years (1956-1963) that the autonomous control
program and the high-level language compiler were developed.
When in 1964 I became manager of Operating System/360, I
found a programming world quite changed by the progress of
the previous few years.
Managing OS/360 development was a very educational ex-
perience, albeit a very frustrating one. The team, including F.
M.
Trapnell who succeeded me as manager, has much to be proud
of. The system contains many excellencies in design and exe-
cution, and it has been successful in achieving widespread use.
Certain ideas, most noticeably device-independent input-output
and external library management, were technical innovations
Preface to the First Edition, xi

now widely copied. It is now quite reliable, reasonably
efficient,
and very versatile.
The effort cannot be called wholly successful, however. Any
OS/360 user is quickly aware of how much better it should be.
The flaws in design and execution pervade especially the
control
program, as distinguished from the language compilers. Most of
these flaws date from the 1964-65 design period and hence must
be laid to my charge. Furthermore, the product was late, it took
more memory than planned, the costs were several times the
estimate, and it did not perform very well until several releases
after the first.
After leaving IBM in 1965 to come to Chapel Hill as origi-
nally agreed when I took over OS/360, I began to analyze the
OS/360 experience to see what management and technical les-
sons were to be learned. In particular, I wanted to explain the
quite different management experiences encountered in System/
360 hardware development and OS/360 software development.
This book is a belated answer to Tom Watson's probing ques-
tions as to why programming is hard to manage.
In this quest I have profited from long conversations with
R. P. Case, assistant manager 1964-65, and F. M, Trapnell,
man-
ager 1965-68.1 have compared conclusions with other managers
of jumbo programming projects, including F. J. Corbato of
M.I.T., John Harr and V. Vyssotsky of Bell Telephone Labora-
tories, Charles Portman of International Computers Limited,
A. P. Ershov of the Computation Laboratory of the Siberian Di-
vision, U.S.S.R. Academy of Sciences, and A. M. Pietrasanta of
IBM.
My own conclusions are embodied in the essays that follow,

which are intended for professional programmers, professional
managers, and especially professional managers of program-
mers.
Although written as separable essays, there is a central ar-
gument contained especially in Chapters 2-7. Briefly, I believe
that large programming projects suffer management problems
xii Preface to the First Edition
different in kind from small ones, due to division of labor. I be-
lieve the critical need to be the preservation of the conceptual
integrity of the product itself. These chapters explore both the
difficulties of achieving this unity and methods for doing so.
The later chapters explore other aspects of software engineering
management.
The literature in this field is not abundant, but it is widely
scattered. Hence I have tried to give references that will both
illuminate particular points and guide the interested reader to
other useful works. Many friends have read the manuscript,
and some have prepared extensive helpful comments; where
these seemed valuable but did not fit the flow of the text, I have
included them in the notes.
Because this is a book of essays and not a text, all the ref-
erences and notes have been banished to the end of the volume,
and the reader is urged to ignore them on his first reading.
I am deeply indebted to Miss Sara Elizabeth Moore, Mr.
David Wagner, and Mrs. Rebecca Burns for their help in pre-
paring the manuscript, and to Professor Joseph C. Sloane for ad-
vice on illustration.

Chapel Hill, N.C. F. P. B., Jr
October 1974
Preface to the 20th Anniversary Edition vii
Preface to the First Edition .. x
Chapter 1 The Tar Pit 3
Chapter 2 The Mythical Man-Month 13
Chapter 3 The Surgical Team 29
Chapter 4 Aristocracy, Democracy, and System Design 41
Chapter 5 The Second-System Effect 53
Chapter 6 Passing the Word 61
Chapter 7 Why Did the Tower of Babel Fail? ,. 73
Chapter 8 Calling the Shot 87
Chapter 9 Ten Pounds in a Five-Pound Sack 97
Chapter 10 The Documentary Hypothesis 107
Chapter 11 Plan to Throw One Away 115
Chapter 12 Sharp Tools ,, 127
Chapter 13 The Whole and the Parts 141
Chapter 14 Hatching a Catastrophe , 153

Chapter 15 The Other Face 163
Chapter 16 No Silver Bullet—Essence and Accident 177
Chapter 17 "No Silver Bullet" Refired 205
Chapter 18 Propositions of The Mythical Man-Month:
True or False? 227
Chapter 19 The Mythical Man-Month after 20 Years - 251
Epilogue 291
Notes and References 293
Index 309
X l l l
Een schip op het strand is een baken in zee.
{A ship on the beach is a lighthouse to the sea. ]
DUTCH PROVERB
C R. Knight, M ural of L a Brea Tar Pits
The George C. Page Museum of La Brea Discoveries,
The N atural History Museum of Los Angeles County

3
The Tar Pit
No scene from prehistory is quite so vivid as that of the mortal
struggles of great beasts in the tar pits. In the mind's eye one
sees
dinosaurs, mammoths, and sabertoothed tigers struggling
against
the grip of the tar. The fiercer the struggle, the more entangling
the
tar, and no beast is so strong or so skillful but that he ultimately
sinks.
Large-system programming has over the past decade been
such a tar pit, and many great and powerful beasts have
thrashed
violently in it. Most have emerged with running systems—few
have met goals, schedules, and budgets. Large and small,
massive
or wiry, team after team has become entangled in the tar. No
one
thing seems to cause the difficulty—any particular paw can be
pulled away. But the accumulation of simultaneous and interact-
ing factors brings slower and slower motion. Everyone seems to
have been surprised by the stickiness of the problem, and it is
hard
to discern the nature of it. But we must try to understand it if
we
are to solve it.
Therefore let us begin by identifying the craft of system pro-
gramming and the joys and woes inherent in it.

The Programming Systems Product
One occasionally reads newspaper accounts of how two
program-
mers in a remodeled garage have built an important program
that
surpasses the best efforts of large teams. And every programmer
is prepared to believe such tales, for he knows that he could
build
any program much faster than the 1000 statements/year reported
for industrial teams.
Why then have not all industrial programming teams been
replaced by dedicated garage duos? One must look at what is
being
produced.
In the upper left of Fig. 1.1 is a program. It is complete in
itself,
ready to be run by the author on the system on which it was
developed. That is the thing commonly produced in garages, and
4
The Programming Systems Product 5
Fig. 1.1 Evolution of the programming systems product
that is the object the individual programmer uses in estimating
productivity.
There are two ways a program can be converted into a more
useful, but more costly, object. These two ways are represented

918191ISMM1-UC 752SYSTEMS ANALYSISFall 2019 –.docx

918191ISMM1-UC 752SYSTEMS ANALYSISFall 2019 –.docx

Recommended

Recommended

More Related Content

Similar to 918191ISMM1-UC 752SYSTEMS ANALYSISFall 2019 –.docx

Similar to 918191ISMM1-UC 752SYSTEMS ANALYSISFall 2019 –.docx (20)

More from sodhi3

More from sodhi3 (20)

Recently uploaded

Recently uploaded (20)

918191ISMM1-UC 752SYSTEMS ANALYSISFall 2019 –.docx