CS 4321 – Ch 11
Managing the Software Process
Sections
11.1-11.7
Pages
425-455
***Some of these notes are copied directly from the PP slides that accompany the text.
Section 11.1 – What is Project Management?
1. All the activities needed to plan and execute a project.
2. All the activities related to, “...planning, organizing, and managing resources to bring about the successful
completion of specific project goals and objectives.”














Deciding what needs to be done
Estimating costs
Ensuring there are suitable and available people and resources to undertake the project
Defining responsibilities
Scheduling
Making arrangements for the work
Directing
Being a technical leader
Reviewing and approving decisions made by others
Building morale and supporting staff
Monitoring and controlling the software process
Co-ordinating the work with managers of other projects
Reporting to higher management
Continually striving to improve the process
Section 11.2 – Software Process Models
1. What is a Software Process Model?







Defines the organization of a project into activities.
Helps project manager decide what work is to be done and in what sequence
The models should be seen as aids to thinking, not rigid prescriptions of the way to do things.
Each project ends up with its own unique plan.
All software projects follow a software development process, which is usually explicit.
These terms are synonymous: software lifecycle, software (development) process
There are a number of software process models which define the general outline of the software
development process: Opportunistic, Waterfall, Phased, Structured System, Spiral, Concurrent Engineering,
Test Driven Development, eXtreme Programming, Unified Process,
1
Section 11.2 – The Opportunistic Approach
1. This is what occurs when an organization does not follow good engineering practices.





It does not acknowledge the importance of working out the requirements and the design before
implementing a system.
The design of software deteriorates faster if it is not well designed.
Since there are no plans, there is nothing to aim towards.
There is no explicit recognition of the need for systematic testing and other forms of quality assurance.
The above problems make the cost of developing and maintaining software very high.
First
Prototype
Modify
Until
Satisfied
Think of Idea
for
Improvement
Section 11.2 – The Waterfall Model
1. To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner.



The model suggests that software engineers should work in a series of stages.
Before completing each stage, they should perform quality assurance (verification and validation).
The waterfall model also recognizes, to a limited extent, that you sometimes have to step back to earlier
stages.

Origins in the manufacturing and construction industries
o Highly structured physical environments in which after-the-fact changes are prohibitively costly, if not
impossible.
o Since no formal software development methodologies existed at the time, this hardware-oriented
model was simply adapted for software development.
Today, use of the term, waterfall model, tends to be in a derisive tone.
It was first described in 1970, however, it was described as flawed.


2
2. Waterfall Model Support







Estimated that a bug undetected in requirements or design will cost 50-200 times as much to fix after
implementation.
Emphasis on documentation, makes changes easier, easier for new people to become involved.
Disciplined
Suitable for stable projects, with unchanging requirements, such as shrink-wrap software
High-risk projects, large defense contracts
Big Design Up Front (BDUF)
Sashimi Model, phases overlap
3. Waterfall Model Criticism







Impossible in practice to complete one phase before beginning another
Impossible to get the requirements right the first time
Can get the requirements right by simply writing them down
Limitations of a design cannot be known until implemented
“Measure twice, cut once”, but what we are measuring is constantly changing
More closely a project follows Waterfall, the more features it produces that are not used
Can’t use anything until entire system is complete
Section 11.2 – The Phase Release Model
1. It introduces the notion of incremental development.




After requirements gathering and planning, the project should be broken into separate subprojects, or
phases.
Each phase can be released to customers when ready.
Parts of the system will be available earlier than when using a strict waterfall approach.
However, it continues to suggest that all requirements be finalized at the start of development.
3
Section 11.2 – Structured Systems Analysis and Design Method (SSADM)




Waterfall approach by which an information system design can be arrived at. Very rigid approach.
Logical Data Modeling - Identifying, modeling and documenting the data requirements of the system being
designed.
Data Flow Modeling - Identifying, modeling and documenting how data moves around an information system.
Entity Behavior Modeling - Identifying, modeling and documenting the events that affect each entity and the
sequence in which these events occur.
Section 11.2 – Iterative Processes



Iterative development prescribes the construction of initially small, but ever larger portions of a software project
Helps uncover important issues early before problems or faulty assumptions can lead to disaster.
Helps reach the design goals of a customer who does not know how to define what they want.
Section 11.2 – The Spiral Model
1. It explicitly embraces prototyping and is an iterative approach to software development.






Start by developing a small prototype.
Followed by a mini-waterfall process, primarily to gather requirements.
Then, the first prototype is reviewed.
In subsequent loops, the project team performs further requirements, design, implementation and review.
The first thing to do before embarking on each new loop is risk analysis.
Maintenance is simply a type of on-going development.
4
Section 11.2 – The Evolutionary Model
1. It shows software development as a series of hills, each representing a separate loop of the spiral.
 Shows that loops, or releases, tend to overlap each other.
 Makes it clear that development work tends to reach a peak, at around the time of the deadline for
completion.
 Shows that each prototype or release can take
o different amounts of time to deliver;
o differing amounts of effort.
Section 11.2 – The Concurrent Engineering Model
1. It explicitly accounts for the divide and conquer principle.


Each team works on its own component, typically following a spiral or evolutionary approach.
There has to be some initial planning, and periodic integration.
5
Section 11.2 – Test Driven Development (TDD)




Write automated unit tests that define the code requirement before writing the code
Make sure test case fails initially. Ensures that the test really works and can catch an error.
Easy to “step back” with unexpected failure
Tests have shown that coders are more productive with this approach
6
Section 11.2 – Rapid Application Development (RAD)



Minimal planning in favor of prototyping
Problematic for multi-team distributed system development
There are many RAD tools that facilitate RAD. MS Visual Studio is one. With VS you can develop a complete
database application (desktop or web) with the programmer writing almost no code, in minutes!
Section 11.2 – Agile Approaches






Built on the foundation of iterative development, using very small iterations
Lighter, more people-centric viewpoint than traditional approaches.
Use feedback, rather than planning, as their primary control mechanism.
Feedback is driven by regular tests and releases of the evolving software.
Well suited for small projects that involve uncertain, changing requirements and other high risk features
There are many implementation of Agile methods: Agile Unified Process (AUP), Dynamic Systems Development
Method (DSDM), Extreme Programming (XP), Feature Driven Development (FDD), Open Unified Process
(OpenUP), Scrum.
Section 11.2 – eXtreme Programming (XP)










Intends to improve software quality and be responsive to changing requirements
Highest priority is customer satisfaction
All stakeholders work closely together daily throughout the project
User stories are written instead of requirement document
There must be a series of small and frequent releases (1 to 3 weeks)
Test cases are written before the software is developed
A large amount of refactoring is encouraged
Pair programming is recommended
Global awareness – at any point in time, all team members can measure progress toward customer’s objectives.
XP Activities





Coding
Testing
Listening - Programmers must listen to what the customers need the system to do, what "business logic" is
needed.
Designing
XP Values





Communication
Simplicity
Feedback from the system, customer, team
Courage – to refactor, to code for today-not tomorrow, when to throw code away, to be persistent
Respect – developers respect each other, flat management structure, all team members are appreciated,
don’t delay the work of others
7
Section 11.2 – Scrum



Iterative, incremental framework for managing complex projects
During each "sprint", typically a two to four week period (with the length being decided by the team), the team
creates a potentially shippable product increment (for example, working and tested software).
The set of features that go into a sprint come from the product "backlog," which is a prioritized set of high level
requirements of work to be done.
Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting,
the Product Owner informs the team of the items in the product backlog that he or she wants completed.
The team then determines how much of this they can commit to complete during the next sprint

Daily Scrum


Each day during the sprint, a project status meeting occurs. This is called a "daily scrum", or "the daily
standup". This meeting has specific guidelines:








The meeting starts precisely on time.
All are welcome, but only "pigs" may speak
The meeting is timeboxed to 15 minutes
The meeting should happen at the same location and same time every day
During the meeting, each team member answers three questions:
What have you done since yesterday?
What are you planning to do today?
Do you have any problems preventing you from accomplishing your goal? (resolved outside of Daily
Scrum)
8
Section 11.2 – The IBM Rational Unified Process
This is the most widely known methodology that embraces UML





Designed to be adaptable
Suggests a process framework
Adapts to the project needs
Use-case-driven development
Architecture-centric process
IBM Rational Unified Process



The Rational Unified Process (RUP) is an iterative software development process framework created by the
Rational Software Corporation, a division of IBM since 2003.
It is also a software product to support this process.
RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to
be tailored by the development organizations and software project teams that will select the elements of
the process that are appropriate for their needs.
RUP Lifecycle Phases




Inception
Elaboration
Construction
Transition
RUP Best Practices



Develop iteratively
Manage requirements
Use components
9



Model visually - Use diagrams to represent all major components, users, and their interaction. UML is one
tool that can be used to make this task more feasible.
Verify quality
Control changes
10
Section 11.2 – Choosing a process model





From the waterfall model:
o Incorporate the notion of stages.
From the phased-release model:
o Incorporate the notion of doing some initial high-level analysis, and then dividing the project into
releases.
From the spiral model:
o Incorporate prototyping and risk analysis.
From the evolutionary model:
o Incorporate the notion of varying amounts of time and work, with overlapping releases.
From concurrent engineering:
o Incorporate the notion of breaking the system down into components and developing them in
parallel.
Section 11.2 – Reengineering
1. Periodically project managers should set aside some time to re-engineer part or all of the system
 The extent of this work can vary considerably:
o Cleaning up the code to make it more readable.
o Completely replacing a layer.
o Re-factoring part of the design.
 In general, the objective of a re-engineering activity is to increase maintainability.
Section 11.3 – Effort Estimation
1. Software Managers must make estimates about projects with varying amounts of information as input. They
need to estimate:
 Elapsed time – how much time will the project take from start date to end date.
 Development effort – how much effort will be expended to complete the project. This is usually measured in
man-months (person-months) which is how many hours a person works in a month. Exactly how many hours
are there in a man-month? That depends on lots of things including culture norms. One study showed about
115 hours for the Netherlands, on one extreme to 193 hours in South Korea. In America, it may be from 150
to 165 hours. http://en.wikipedia.org/wiki/Man-hour
 Development cost – To convert an estimate of development effort to an amount of money you multiply it by
the weighted average cost (burdened cost) of employing a software engineer for a month (or a day).
 Number of developers – Divide development effort by elapsed time.
2. How is estimation done? - Published surveys on estimation practice suggest that expert estimation is the
dominant strategy when estimating software development effort.
http://en.wikipedia.org/wiki/Software_development_effort_estimation
Other strategies utilize formal models as we will discuss later.
11
3. Principles of effective cost estimation:
a. Principle 1: Divide and conquer.
 To make a better estimate, you should divide the project up into individual subsystems.
 Then divide each subsystem further into the activities that will be required to develop it.
 Next, you make a series of detailed estimates for each individual activity.
 And sum the results to arrive at the grand total estimate for the project.
b. Principle 2: Include all activities when making estimates. The time required for all development activities
must be taken into account:
prototyping, design, inspecting, testing, debugging, writing user documentation, deployment, training,
planning and scheduling, meetings, etc.
c. Principle 3: Base your estimates on past experience combined with knowledge of the current project.



If you are developing a project that has many similarities with a past project. you can expect it to take a
similar amount of work.
Base your estimates on the personal judgement of your experts and/or
Use algorithmic models developed in the software industry as a whole by analyzing a wide range of
projects. More on this later.
d. Principle 4: Be sure to account for differences when extrapolating from other projects. Different: software
developers, development processes and maturity levels, types of customers and users, schedule demands,
technology, technical complexity of the requirements, domains, levels of requirement stability.
e. Principle 5: Anticipate the worst case and plan for contingencies. Make three estimates:
— Optimistic (O)
- Imagining a everything going perfectly
— Likely (L)
- Allowing for typical things going wrong
— Pessimistic (P)
- Accounting for everything that could go wring
f.
Principle 6: Combine multiple independent estimates.
 Use several different techniques and compare the results.
 If there are discrepancies, analyze your calculations to discover what factors causing the differences.
 Use the Delphi technique.
• Several individuals initially make cost estimates in private.
• They then share their estimates to discover the discrepancies.
• Each individual repeatedly adjusts his or her estimates until a consensus is reached
g. Principle 7: Revise and refine estimates as work progresses
 As you add detail.
 As the requirements change.
 As the risk management process uncovers problems
12
4. Algorithmic models
a. Allow you to systematically estimate development effort based on an estimate of some other factor that
you can measure, or that is easier to estimate:
— The number of use cases
— The number of distinct requirements
— The number of classes in the domain model
— The number of widgets in the prototype user interface
— An estimate of the number of lines of code
b. A typical algorithmic model uses a formula like the following:
— COCOMO: E = a + bNc
— Functions Points: S = W1F1 + W2F2 +W3F3 + …
— SLIM: 𝐸 = [
3
𝑆𝑖𝑧𝑒
4
] ∗𝐵
𝑃𝑟𝑜𝑑𝑢𝑐𝑡𝑖𝑣𝑖𝑡𝑦∗ 𝑇𝑖𝑚𝑒 3
http://en.wikipedia.org/wiki/Putnam_model
— SEER-SEM
http://en.wikipedia.org/wiki/SEER-SEM
— Others
c. Estimating Lines of Code
1. The Mythical Man-Month (by Frederick P. Brooks) describes a study at IBM that compared the
productivity of programmers. It showed that the best programmers were 30 times more productive than
the worst and that they were 10 times more productive than the average.
2. How big is big?
Year
1993
1994
1996
2000
2002
2007
Windows Version LOC
Windows NT 3.1 6 million
Windows NT 3.5 10 million
Windows NT 4.0 16 million
Windows 2000 29 million
Windows XP
40 million
Windows Vista ~50 million
Operating System SLOC (Million)
Debian 2.2
55-59[2][3]
Debian 3.0
104[3]
Debian 3.1
215[3]
Debian 4.0
283[3]
Debian 5.0
324[3]
OpenSolaris
9.7
FreeBSD
8.8
Mac OS X 10.4
86[4]
Linux kernel 2.6.0 5.2
Linux kernel 2.6.29 11.0
Linux kernel 2.6.32 12.6[5]
http://www.informationisbeautiful.net/visualizations/million-lines-of-code/
https://docs.google.com/spreadsheet/ccc?key=0Aqe2P9sYhZ2ndElxbjVTcnV2bHFOWmUwSkt2bjZLd
VE&usp=drive_web#gid=5
13
d. Section 11.3 – COCOMO
1. COCOMO (COnstructive COst MOdel)
2. COCOMO predicts the effort and schedule for a software product development based on inputs relating
to the size of the software and a number of cost drivers that affect productivity
3. There are three different models that give increasingly more precise results: Basic, Intermediate,
Detailed
4. COCOMO uses a basic regression formula with parameters that are derived from historical project data
and the current project. The Basic model is:
𝐸 = 𝑎𝑁 𝑏
Where
a. N is the number of thousands of lines of delivered code (KLOC).
b. E is the total effort in person-months.
c. a and b are parameters to be discussed shortly
5. A person-month is the amount of time one person works in a month. Thus a project that takes 24
person-months of effort could be done by 1 person in 2 year’s time, 2 people in 1 year’s time, 4 people
in 6 month’s time, etc.
6. Project Characteristics
Project Type
Organic
Semi-detached
Embedded
a
2.4
3.0
3.6
b
1.05
1.12
1.20
c
2.5
2.5
2.5
d
0.38
0.35
0.32
a. Organic Mode
 Relatively small, simple software projects
 Small teams with good application experience work to a set of less than rigid requirements
 Similar to the previously developed projects
 relatively small and requires little innovation
b. Semidetached Mode
 Intermediate (in size and complexity) software projects in which teams with mixed
experience levels must meet a mix of rigid and less than rigid requirements.
c. Embedded Mode
 Software projects that must be developed within a set of tight hardware, software, and
operational constraints.
14
7. Assumptions
a. Primary cost driver is the number of delivered lines of code
b. COCOMO estimates assumes good management
c. Assumes the requirements specification doesn’t change much.
8. Advantages of Basic COCOMO:
a. Basic COCOMO is good for quick, early, rough order of magnitude estimates of software costs
b. It does not account for differences in hardware constraints, personnel quality and experience, use of
modern tools and techniques, and other project attributes known to have a significant influence on
software costs, which limits its accuracy
9. Limitations
a. Its accuracy is necessarily limited because of its lack of factors which have a significant influence on
software costs
b. The Basic COCOMO estimates are within a factor of 1.3 only 29% of the time, and within a factor of
2 only 60% of the time
10. Other formulas:



𝐸 = 𝑎𝑁 𝑏 (mentioned above)
𝑇 = 𝑐𝐸 𝑑
𝑃 = 𝐸/𝑇
Where:
T = development time in months
P = number of people required
a,b,c,d = parameters in table above.
11. Example – Suppose a project fits the semi-detached characteristic and we estimate we will have 32,000
delivered lines of code.



𝐸 = 3.0 ∗ 321.12 = 145.5 person-months
𝑇 = 2.5 ∗ 1460.35 = 14.3 months
145.5
𝑃 = 14.3 = 10.2 people

𝑃𝑟𝑜𝑑𝑢𝑐𝑡𝑖𝑣𝑖𝑡𝑦 =
32,000 𝐾𝐿𝑂𝐶
145.5 𝑃𝑀
= 220 𝐾𝐿𝑂𝐶/𝑃𝑀
15
e. Section 11.3 – Function Point Analysis
1. Function Point Analysis (FPA) is designed (similar to COCOMO) to estimate and measure the time, and
thereby the cost, of developing new software applications and maintaining existing software
applications.
a. It was developed by A.J. Albrecht of the IBM Corporation in the early 1980s.
b. In order to estimate size, it uses function points instead of KLOC
2. Idea: count the number of: Inputs, Outputs, Files, Inquiries, Interfaces. Weight each by the degree of
complexity:
Category
Inputs
Outputs
Files
Inquiries
Interfaces
Simple Average Complex
2
4
6
3
5
7
5
10
15
2
4
6
4
7
10
3. A simple example
Inputs
3 simple
4 average
1 complex
Outputs
6 average
2 complex
Files
5 complex
Inquiries
8 average
Interfaces
3 average
4 complex
X 2 = 6
X 4 = 16
X 6 = 6
X 5 = 30
X 7 = 14
X 15 = 75
X 4 = 32
X 7 = 21
X 10 = 40
Unadjusted function points = 240
4. Adjustment Factor - In addition to these individually weighted function points, there are factors that
affect the project and/or system as a whole. There are a number (~35) of these factors that affect the
size of the project effort, and each is ranked from “0”- no influence to “5”- essential. The following are
some examples of these factors:
1. Is high performance critical?
2. Is the internal processing complex?
3. Is the system to be used in multiple sites and/or by multiple organizations?
4. Is the code designed to be reusable?
5. Is the processing to be distributed?
6. . . .
16
𝐴𝑑𝑗𝑢𝑠𝑡𝑒𝑑 𝐹𝑃 = 𝑈𝑛𝑎𝑑𝑗𝑢𝑠𝑡𝑒𝑑 𝐹𝑃 ∗ [0.65 + (𝐴𝑑𝑗𝑢𝑠𝑡𝑚𝑒𝑛𝑡 𝐹𝑎𝑐𝑡𝑜𝑟 ∗ 0.01)].
5. Continuing our example . . .
Complex internal processing
Code to be reusable
High performance
Multiple sites
Distributed processing
Project adjustment factor
= 3
= 2
= 4
= 3
= 5
= 17
Adjusted FP = Unadjusted FP X [0.65 + (adjustment factor X 0.01)]
=
240
X [0.65 + (
17
X 0.01)]
=
240
X [0.82]
=
197 Adjusted function points

How long will the project take and how much will it cost?
For example, past data shows that programmers in our organization average 18 function points per
month. Thus:
197 FP / 18 (FP/PM) = 11 PM

If the burdened cost of labor is $7,200 per month, then the [labor] cost of the project will be . . .
11 man-months X $7,200 = $79,200
6. Because function point analysis is independent of language used, development platform, etc. it can be
used to identify the productivity benefits of:
a.
b.
c.
d.
e.
One programming language over another
One development platform over another
One development methodology over another
One programming department over another
Before-and-after gains in investing in programmer training
17
Section 11.4 – Building Software Engineering Teams
1. Software engineering is a human process.
 Choosing appropriate people for a team, and assigning roles and responsibilities to the team members, is
therefore an important project management skill
 Software engineering teams can be organized in many different ways
2. Quotes:



Brooks’ Law (1975) – “Adding manpower to a late project only makes it later.” Why?
John S. MacDonald, MacDonald Dettwiler - “There is no substitute for careful planning and team formation
if overruns and later confusion, not to mention disaster, are to be avoided.”
R. E. Fairley – [The trick in software engineering is to find out] how to do intellectually-intensive work in
teams."
3. Team Organization:
a) Eg oles s
b) Chi ef p rogram mer
c) Strict hi erarchy
4. Software Teams – Organizing People


Useful to organize people in terms of their specialties, a matrix of specialties and skills.
Subsystems and teams should be sized such that the total amount of required knowledge and exchange of
information is reduced. Increase cohesion and reduce coupling in systems and teams.
18
Section 11.5 – Project Scheduling and Tracking


Scheduling is the process of deciding:
1. In what sequence a set of activities will be performed.
2. When they should start and be completed.
Tracking is the process of determining how well you are sticking to the cost estimate and schedule. Process
control, or statistical process control.
Section 11.5 – PERT Charts








Program Evaluation and Review Technique
A PERT chart shows the sequence in which tasks must be completed.
In each node of a PERT chart, you typically show the elapsed time and effort estimates.
The critical path indicates the minimum time in which it is possible to complete the project.
Used more in projects where time, rather than cost, is the major factor.
It is applied to very large-scale, complex, non-routine projects.
Can be thought of as a weighted graph where nodes are milestones and edge weights are the estimated
time to complete a task.
Critical Path: the longest possible continuous pathway taken from the initial event to the terminal event. It
determines the total calendar time required for the project; and, therefore, any time delays along the
critical path will delay the reaching of the terminal event by at least the same amount.
19
Section 11.5 – Gantt Charts








A Gantt chart is used to graphically present the start and end dates of each software engineering task
One axis shows time.
The other axis shows the activities that will be performed.
The black bars are the top-level tasks.
The white bars are subtasks
The diamonds are milestones: Important deadline dates, at which specific events may occur
Can be colored to show percent complete.
Can have actual and planned versions of Gantt charts.
20
Section 11.5 – Earned Value
Earned value



The cumulative budget for this project as a function of time is shown (the blue line, labeled PV).
The cumulative actual cost of the project (red line, labeled AC)
Quantify the accomplishment of work. At the end of each week, the project manager identifies every
detailed element of work that has been completed, and sums the PV for each of these completed elements.
This is call earned value (green line, labeled EV).
An earned value chart has three curves:
 The budgeted cost of the work scheduled.
 The earned value.
 The actual cost of the work performed so far.
21
Section 11.6 – Contents of a Project Plan
A.
B.
C.
D.
E.
F.
G.
H.
I.
Purpose
Background information
Processes to be used
Subsystems and planned releases
Risks and challenges
Tasks
Cost estimates
Team
Schedule and milestones
22
Section 11.7 – Difficulties and Risks in Project Management





Accurately estimating costs is a constant challenge
o Follow the cost estimation guidelines.
It is very difficult to measure progress and meet deadlines
o Improve your cost estimation skills so as to account for the kinds of problems that may occur.
o Develop a closer relationship with other members of the team.
o Be realistic in initial requirements gathering, and follow an iterative approach.
o Use earned value charts to monitor progress.
Lack of human resources and technology
Communicating effectively in a large project is hard
o Take courses in communication, both written and oral.
o Learn how to run effective meetings.
o Review what information everybody should have, and make sure they have it.
o Make sure that project information is readily available.
o Use ‘groupware’ technology to help people exchange the information they need to know
It is hard to obtain agreement and commitment from others
o Take courses in negotiating skills and leadership.
o Ensure that everybody understands: (a) The position of everybody else. (b) The costs and benefits of
each alternative. (c) The rationale behind any compromises.
o Ensure that everybody’s proposed responsibility is clearly expressed.
o Listen to everybody’s opinion, but take assertive action, when needed, to ensure progress occurs.
Risks Management
During project planning, use a risk management strategy such as the following:
1. Identify risk factors
2. Determine risk exposure. If risk factors are realized, how will the effect cost and schedule?
3. Develop strategies to mitigate risks
4. Monitor risks
Chapter 11 - Homework
1. Briefly describe the Software Process Models (Waterfall, Phase Release, Spiral, Evolutionary, Test Driven
Development, Agile/XP/Scrum
2. Describe when the waterfall model would be appropriate.
3. Describe when Agile techniques would be appropriate.
4. Describe the term reengineering.
5. Describe the two major time estimates that must be made for a software engineering project.
6. Describe three estimation principles.
7. Briefly describe how algorithmic estimation methods work in general
8. (omit) Briefly describe three different types of software teams.
9. (omit) When is the egoless team structure best suited?
10. List two major types of charts used for project scheduling and tracking.
23