Docsity
Log inSign up
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search Store documents

The best documents sold by students who completed their studies

Search through all study resources
Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

University Rankings

Discover the best universities in your country according to Docsity users

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

From our blog

Exams and Study
Go to the blog

Insights on Conceptual Integrity in Large Software Projects: Fred Brooks, Exams of Software Engineering

West Virginia Career InstituteSoftware Engineering

Insights from Fred Brooks' book 'The Mythical Man-Month' about the challenges of managing large software development projects, focusing on the importance of preserving conceptual integrity and effective communication among team members. It covers topics such as the tar pit of large system programming, the mythical man-month, communication and coordination among team members, and the importance of planning and testing.

What you will learn

  • What is the role of planning and testing in software development projects?
  • What is the impact of communication and coordination among team members on software development projects?
  • How does the concept of the 'mythical man-month' impact software development projects?
  • What are the challenges of managing large software development projects?
  • How can conceptual integrity be preserved in large software development projects?

Typology: Exams

2021/2022

Uploaded on 09/12/2022

mjforever
mjforever 🇺🇸

4.8

(25)

258 documents

1 / 25

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
-1-UTA CSE
The Mythical Man-Month: Essays on
Software Engineering
by
Frederick P. Brooks, Jr.
•Brooks => Manager for Architecture & Operating System (OS360)
development for IBM360 & was also involved in design and
implementation of the IBM Stretch.
•OS360 is an important product since it introduced several innovative
ideas such as:
•Device independent I/O
•External Library Management
•This book is for professional managers of software development
projects.
•Brooks believes large program development management suffers
from problems related to division of labor.
•Brooks says critical problem is preservation of conceptual integrity
of the product itself => he will propose methods for preserving this
unity in Chpt's 2-7.
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19

Partial preview of the text

Download Insights on Conceptual Integrity in Large Software Projects: Fred Brooks and more Exams Software Engineering in PDF only on Docsity!

The Mythical Man-Month: Essays on

Software Engineering

by Frederick P. Brooks, Jr.

  • Brooks => Manager for Architecture & Operating System (OS360) development for IBM360 & was also involved in design and implementation of the IBM Stretch.
  • OS360 is an important product since it introduced several innovative ideas such as:
  • Device independent I/O
  • External Library Management
  • This book is for professional managers of software development projects.
  • Brooks believes large program development management suffers from problems related to division of labor.
  • Brooks says critical problem is preservation of conceptual integrity of the product itself => he will propose methods for preserving this unity in Chpt's 2-7.
  • Chpt 1: The Tar Pit
  • Large system programming is like a tar pit:
  • The more you struggle, the more you sink in it.
  • No one thing seems to be the difficulty, but as a whole, the programmers get trapped in it and the project dies (e.g., we can take one paw or hand out of the tar pit, but not our whole body).
  • A programming system product must be:
    • 1) General (for input, as well as algorithms).
    • 2) Thoroughly tested so it can be depended upon. This increases costs be as much as 3 times over untested products.
    • 3) Documented so it can be used, fixed, and extended.
    • 4) Finally, a programming product becomes a component of a software system (it works with other programs and can be called or interrupted) => I/O interfaces become very important => a programming product must be tested in all possible combinations with other system components. This is very difficult => A programming system product as a system component costs at least 3 times as much as the same program as a programming product.
    • 5) Programming product must be within allotted budget.
  • A programming system product is 9 times higher in cost than a stand-alone product (3 for program testing x 3 for system testing).
  • The second problem with estimating completion time of software projects is with the unit of time used to estimate the completion of the project (i.e., MAN-MONTH).
  • There is a fallacy involved with this unit: It is true that the cost of the project will increase proportional to the MAN-MONTH used for that project. However, the progress is not going to be achieved proportional to the number of MAN-MONTHS used for a project.
  • Therefore, it is a false assumption that by adding more MAN- MONTHS you can complete the project earlier.
  • MAN and MONTH are in fact interchangeable, only if the project consists of several independent efforts (INDEPENDENT PARTITIONED TASKS) and a case where team members do not have to communicate with each other.
  • e.g.: Men for Months Man-Month
  • 5 4 20
  • X2 /
  • 10 2 20
  • In fact, one of the problems with software engineering projects is that as we add more MAN-MONTHS, the amount of communication among the men is going to increase rapidly.
  • Therefore, by adding more MAN-MONTHS, we are, in fact, increasing the completion time of the software project because the communication is going to affect the completion time of the project.
  • Thus, the assumption that MAN and MONTH are interchangeable is not correct.
  • Another very important factor that affects our estimation of completion time of software projects is the system testing and debugging process.
  • Brooks' rule of thumb for estimating the completion time of software projects: - 1/3 time for planning; - 1/6 time for coding; - 1/4 time for component tests; - 1/4 time for system test with all components in hand.
  • Note that the testing and debugging takes about 50% of the time, while coding, which people often worry about, only takes about 1/ of the time.
  • Actually, coding is the easiest phase to accurately estimate!
  • Underestimating the time it takes for system testing can become very dangerous because it comes at the end of the project: - project is already fully funded and has the most manpower allocated to it,
  • Let MMc be the average effort expended by a pair of persons, working on the project, in communicating with each other - determined to be based on the project not N****. Then: - Assumes no original level isolations. But complete communication among team members.
  • MMn = Effort required without communication
  • MM = Total effort including communication:
  • Note : This is appropriate for task force , committee

and democratic organizations. Not so for others.

MMc

N N

= MMc Pairs MMc

∑ ×^ =^ ×

2

MM MMn N

N

MMc N T

T

MMn

N

N

MMc

MMn

N

MMc

N if N let H

MMc

T

MMn

N

H N

= ×

≈ + × >> =

≈ + ×

  • Example : A 100 Man month task requires an

average of 1 Man Month Communications

effort per pair of project personnel. Nopt =?

  • With the 100 MM task effort est., wouldn't it

be a shocker if no consideration of

communication was made!

N

MMn

MMc

Persons

T Months

MM T N Man Month

opt

opt

opt opt

= + × =

∑ =^ ×^ =

  • Chpt 3: The Surgical Team
  • A lot of the program managers believe that they are better off having a very small number of sharp Programmers on their team than having a large number of mediocre programmers.
  • However, the problem with an organization like this is that with such a small number of people in a group you cannot do large system applications and system programs.
  • For example, the OS360 took about 5,000 MAN-YEARS to complete so if we have a small team of 200 programmers it would have taken them 25 years to complete the project!
  • However, it took about 3 years to complete the project and, at times, there were more than 1,000 men working on the project.
  • Now assume that instead of hiring the 200 programmers we hire 10 very smart and productive programmers, therefore, let's say they can achieve an improvement factor of 7 in terms of productivity for programming and documentation, and we can also achieve an improvement factor of 7 in terms of reduced communication among the programmers.
  • In that case, for our 5,000 MAN-YEARS job, we need 10 years to complete the project. (5,000/(10X7X7)).
  • Solution:
  • Scaling up: How does one apply the surgical team organization to a project which involves hundreds or thousands of team members? - The obvious choice is to use a hierarchical organization in which the large system is broken into many subsystems and there are surgical teams assigned to each subsystem. - Of course, there has to be coordination between the subsystems and that will be as coordination between the subsystem team leaders (a few chief programmers).
  • Chpt 4: Conceptual Integrity
  • Conceptual integrity is probably the most important aspect of large system programming.
  • It is better to have one good idea and carry it through the project than having several uncoordinated good ideas.
  • It is important that all the aspects of the system follow the same philosophy and the same conceptual integrity throughout the system. Thus, by doing so, the user or the customer only needs to be aware of or know one concept.
  • The conceptual integrity of the whole system is preserved by having one system architect who designs the system from top-to-bottom.
  • It should be noted that the system architect should stick with the design of the system and should not get involved with the implementation.
  • This is because implementation and design are two separate phases of the project.
  • When we talk about the architect and architecture of a system we are referring to the complete and detailed specifications of all the user interfaces for the software system.
  • The implementation of the system, on the other hand, is what goes on behind the scenes, and what is actually carried out in coding and in programming. - An example is a programming language such as FORTRAN. The architecture of FORTRAN specifies the characteristics of FORTRAN, its syntax and its semantics. However, we can have many implementations of FORTRAN on many different machines.
  • A system architecture is based on user requirements.
  • An architect defines the design spec's while a builder defines the implementation spec's.
  • How is the architecture enforced during the implementation?
    • Manual is the chief product of the architect and it carries the design spec's.
    • Meetings to resolve problems and discuss proposed changes.
    • Product testing.
  • This will be a tool where the team members can go to find out what the newest changes are and what other people are doing.
  • It should be noted that, as the projects become larger and larger, and the number of people involved become more and more, the size of the project workbook increases and we have to impose some kind of a structure for the workbook. For example, we may use a tree structure organization, or we may have to use indexing and numbering systems in order to find what we are looking for.
  • One of the problems to deal with is how to keep track of changes of the project in the workbook. There are two things that need to be done: - 1) All the changes should be clearly highlighted in the documents and this can be done, for example, by a vertical bar in the margin for any line which has been changed. - 2) There should be a brief summary of changes attached, which highlights or explains briefly the significance of the changes done to the project.
  • Organization:
    • Organization is a means to control communication in a project.
    • We have already talked about tree organization, as well as matrix organization, and also we have talked about the communication involved in each structure.
    • For example, in the tree organization we see a clear division of responsibilities and the communication becomes limited among subordinates and the supervisors.
  • Chpt 11: Plan to Throw One Away
  • Building a pilot model or a pilot system is an intermediate step between the initial system implementation (or prototyping) and the final large-scale system.
  • Building a pilot model is necessary in order to overcome the difficulties unforeseen when going from a small-scale project to a large-scale project.
  • The pilot system should be thrown away and should not be given to the customer as a final model. This is because the pilot model often has bugs in it and would reduce the customer's confidence in the producer.
  • Software Maintenance:
    • The major difference between software maintenance and hardware maintenance is that in hardware maintenance we simply repair or replace components and the architecture and the interface to the user doesn't change.
    • However, in software maintenance we make design changes to the software and typically add new functions and because of this, the interface to the user changes.
    • Also, in software maintenance, fixing the problems and new functions also introduce new bugs which requires further testing.
    • What typically happens is that as we add more functions, we are adding more bugs which in turn requires more fixes and modifications. Therefore, software maintenance is a very difficult job.