Topic: management of large software projects

topics > computer science > programming > Group: software engineering

software maintenance

bug tracking system
change notification
managing people
public domain software
software lifecycle
software management
software change management
software metrics
software review
team programming
testing testing
version control

Subtopic: management up

Quote: organize programming as distinct activities with clearly defined interactions
Quote: every approach works for a small project, and with enough time and money, for a large project [»stroB_1991]
Quote: a list of characteristics of winning generals; important for managing super large system development [»joneTC1_1977]
Quote: law of conservation of organizational stability: the size of a programming project will remain statistically invariant [»lehmMM9_1980]
Quote: must divide projects into sub-projects before adding staff, but hasty decisions leads to poor usability and a weak internal structure [»parnDL8_1971]

Subtopic: communication problems up

Quote: for both people and programs separating implementation from interface is easy; the hard part is organizing effective communication between the different sides of the interface [»stroB_1991]
Quote: constructing a large software system requires communication and coordination [»tichWF9_1979]
Quote: with large systems, documentation, tutorials and system may diverge because documentation is cut when schedules fail [»belaLA_1979]
Quote: what makes a program large is all of its communication requirements; internal, organizational, implementers, users, and operational environment [»belaLA_1979]
Quote: the copy machine was important for designing Multics; increased speed of design interactions [»corbFJ_1979]

Subtopic: scheduling up

Quote: a wallboard schedule worked better than project-planning software; used cards to represent task assignments and duration [»whitS5_1995]

Subtopic: large systems up

Quote: unlike bridge building, progress in software is hard to see; documentation provides conceptual visibility but shouldn't be burdensome [»wegnP_1979a]
Quote: a large software product has an enormous variety of correct implementations [»wegnP_1979a]
Quote: large systems should be constructed for evolutionary change; may require greater overhead during development [»wegnP_1979a]
Quote: programming super large systems is one of the most expensive items in modern business [»joneTC1_1977]
Quote: Lucent's 5ESS telephone switch contains 5,000 modules of 100,000,000 lines of C, C++, and domain specific languages; 20 million lines per release [»puruR6_2005]

Subtopic: product development up

Quote: stages of product development -- concept and brainstorming, refinement to weed out implausible solutions, realization of the product, production in high volume [»colwRP_2006]
Quote: a project must have crystal-clear goals; answer the questions, what constitutes sucess and what constitutes failure [»colwRP_2006]
Quote: preparation before realization; the refinement stage of development selects one alternative and creates the project scaffolding for the realization phase [»colwRP_2006]

Subtopic: waterfall model up

Quote: program large systems by systems requirements, software requirements, program analysis, design, coding, and testing [»roycWW8_1970]
Quote: programming consists of analysis and coding; these steps are not enough for large software systems [»roycWW8_1970]

Subtopic: examples of parallel development up

Quote: telephone switch software has 100M lines of code, 100M lines of headers and make files, 20M lines per release, 50 subsystems, 5000 modules or directories, 10K developers, 15 years [»eickSG4_2002]
Quote: 60 features under development at peak of a #5ESS subsystem release [»perrDE4_1998]
Quote: 9 releases for a #5ESS subsystem under simultaneous feature development
Quote: for a release of a #5ESS subsystem, 25% of the files modified by four or more developers; 50% by two or more [»perrDE4_1998]
Quote: an eighth of all deltas made to the same file by different developers with 24 hours of each other; 3% overlap [»perrDE4_1998]
Quote: operator interaction software changed 150K times by 549 programmers; top 50 programmers made majority of changes, top 2 made 7% of changes [»eickSG4_2002]

Subtopic: parallel development up

Quote: quickly develop a framework for the final system; provides an integration platform, a structure to expand, something to demonstrate, and better work estimates [»huntA_2000]
Quote: Apache has a small core server, a well-defined interface, and various ancillary projects; informal coordination for core team; highly efficient [»mockA7_2002]
Quote: synchronize and stabilize -- evolve designs interactively with frequent synchronization and periodic stabilization [»cusuMA10_1999]
Quote: Microsoft uses synch-and-stabilize, daily build, and zero-defect; work in parallel but synch and debug daily with a shippable product; common language, continuous testing, milestone and release metrics [»cusuMA6_1997]

Subtopic: multiple versions up

Quote: multi-version programs should be easily modified, have useful subsets, and easily extended [»parnDL_1978]
Quote: need manifests and version functions for every component; identifies the implementations of interfaces [»briaM10_1999]
Quote: a successful product leads to many versions; SCV analysis helps to manage the success [»coplJ11_1998]

Subtopic: maintenance up

Quote: software repair should be assigned to those with maximum system overview and insight [»belaLA_1979]
QuoteRef: cheaTE_1976 ;;50 medium scale programs, e.g., data processing applications: either from existing package (e.g., statistics) or from scratch (lots of difficulty here since often do not understand)

Subtopic: design up

Quote: consensus design encouraged too many requirements and generalized designs [»corbFJ_1979]
Quote: in Multics an elaborate macroassembler failed; replaced by a simple, primitive assembler [»corbFJ_1979]
Quote: the program designer must impose performance constraints on the analyst; requires a preliminary design before analysis begins [»roycWW8_1970]

Subtopic: quality assurance up

Quote: given enough eyeballs, all bugs are shallow
Quote: use HyperCode to reduce inspection delays; annotated, diff-marked code listings; online, automatically generated, no meetings [»perrDE7_2002]
Quote: Apache developers do not use QA testing; review code before or after checkin; most core developers review all changes [»mockA7_2002]
Quote: for Apache, open source community used for bug fixing; no coordination needed to identify cause of a bug [»mockA7_2002]
Quote: compares the cathedral model of commercial software vs. the bazaar model of Linux and free software [»raymES3_1998]

Subtopic: project metrics up

Quote: health-of-the-model metric combines regression results, time to debug, forward progress for new functionality, high-priority bugs, and age of open bugs [»colwRP_2006]

Subtopic: cost estimation up

Quote: track the number of new RTL lines per week, the running total and estimates; can predict the final RTL size from the rate of increase [»colwRP_2006]
Quote: project cost estimates only need to prevent really bad, unrecoverable decisions [»armoP11_2002]
Quote: ITT uses a large headquarters' staff to verify estimates and plans of managers [»duns12_1970]
Quote: use analogy to estimate project effort: identify features, estimate effort from similar projects; outperforms algorithmic models such as COCOMO; use at least ten projects [»shepM11_1997]
Quote: effort estimation by analogy and regression analysis works best for builds or enhancements to an existing system and worst for dissimilar projects from multiple organizations [»shepM11_1997]
Quote: predict software effort from regression model of software modification and modification requests [»mockA5_2003]

Subtopic: estimating problems up

Quote: large software projects often fail by orders-of-magnitude miscalculations; modeling and estimation could detect these [»corbFJ_1979]
Quote: project cost estimates only need to prevent really bad, unrecoverable decisions [»armoP11_2002]
Quote: software maintenance tools must account for the long tails of many usage statistics; these are critical cases that need support the most [»perrDE4_1998]
Quote: discover timing, storage, and I/O problems at the end of the development cycle; may require a major redesign and a 100-percent overrun [»roycWW8_1970]
Quote: need to overshoot in selective areas of a design, otherwise unwelcome realities will lead to failure [»colwRP_2006]

Subtopic: performance problems up

Quote: insufficient computer time for building Multics; should have reduced programming staff and bought hardware [»corbFJ_1979]
Quote: as a system grows, need to improve performance [»belaLA_1979]

Subtopic: bug management up

Quote: high numbers of killed or no_change modification requests indicate poor MR quality; waste of time [»eickSG4_2002]

Subtopic: developing system on system up

Quote: Multics development dramatically improved once development moved to Multics (after four years) [»corbFJ_1979]
Quote: with development on Multics, system changes within ten minutes and sometimes seconds [»corbFJ_1979]
Quote: Multics development by new system release once or twice a week; one person responsible [»corbFJ_1979]

Subtopic: release management up

Quote: release manager for each Apache release; identify critical problems, tracks repairs; controls access to the repository [»mockA7_2002]

Related Topics up

Group: software maintenance   (14 topics, 368 quotes)
Group: testing   (18 topics, 557 quotes)

Topic: bug tracking system (34 items)
Topic: change notification (19 items)
Topic: managing people (64 items)
Topic: public domain software (9 items)
Topic: software lifecycle (13 items)
Topic: software management (28 items)
Topic: software change management (48 items)
Topic: software metrics (32 items)
Topic: software review (80 items)
Topic: team programming (7 items)
Topic: testing testing (13 items)
Topic: version control
(34 items)

Updated barberCB 1/06
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.