Development Fundamentals in

RAD
IS 31227
Lecture- 04
Development Fundamentals in RAD
 In software development, one path to success is paying
attention to fundamentals.
 You might have a battery of schedule oriented practices at
your disposal.
 But if you don't put fundamental development practices at the
heart of your development effort, you will seriously risk failing
to meet your schedule goals.
Effect of Fundamentals on Project Schedule

 Fundamental development practices are divided into 3

categories.
◦ Management practices
◦ Technical practices
◦ Quality-assurance practices

 Some of the practices don't fit neatly into one category.

Management Fundamentals
 Management fundamentals have at least as large an influence
on development schedules as technical fundamentals do.
 Management often controls all three corners of the classic
trade-off triangle.
◦ Schedule
◦ Cost
◦ Product
Management Fundamentals
 Management fundamentals consist of
◦ Determining the size of the product.
◦ Allocating resources appropriate for a product of that size.
◦ Creating a plan for applying the resources.
◦ Monitoring and directing the resources.

 Keep the project from heading into the weeds.

Management Fundamentals
 Estimation and Scheduling
Well-run projects go through three basic steps to create a software
schedule.
1.Estimate the size of the project
2.Estimate the effort needed to build a product of that size
3.Estimate a schedule based on the effort estimate
Management Fundamentals
 Estimation and scheduling are development fundamentals
because creating an inaccurate estimate reduces development
efficiency.
 Accurate estimation is essential input for effective planning,
which is essential for efficient development.
Management Fundamentals
 Planning
Planning a software project includes these activities:
◦ Estimation and scheduling.
◦ Determining how many people to have on the project team, what
technical skills are needed, when to add people, and who the people
will be.
◦ Deciding how to organize the team.
Management Fundamentals
 Choosing which lifecycle model to use
 Managing risks
 Making strategic decisions such as how to control the
product's feature set and whether to buy or build pieces of
the product
Management Fundamentals
 Tracking
◦ Once the project is planned and initiated, the project should be
tracked in order to check whether it is following the plan.
◦ Typical management-level tracking controls include task lists, status
meetings, status reports, milestone reviews, budget reports, and
management by walking around
Management Fundamentals
Management Fundamentals
 Tracking is a fundamental software management activity.
 If a project is not tracked, it can't be managed.
◦ No way of knowing whether plans are being carried out.
◦ No way of knowing what should be done next.
◦ No way of monitoring risks to the project.
Management Fundamentals
 Effective tracking enables you to detect schedule problems
early, while there's still time to do something about them.
 If you don't track a project, you can't do rapid development
Management Fundamentals
 Measurement

 One key to long term progression of software organization is

collecting metrics data to analyze software quality and productivity.

 Although projects collect data on costs and schedules, this limited

data doesn't provide much insight into how to reduce the costs or

shorten the schedules.

Management Fundamentals
 If in addition to cost and schedule data, if historical data on software
projects are collected, there will be a basis for planning future
projects that's better than gut instinct.
 A basic knowledge of software measurement is needed to develop
efficiently.
 It is need to understand the issues involved in collecting metrics.
◦ how much or how little data to collect
◦ how to collect it
Management Fundamentals
 There should be a knowledge of specific metrics that can be
used to analyze status, quality, and productivity.
 An organization that wants to develop rapidly needs to collect
basic metrics in order to know what its development speed is
and whether it's improving or degrading over time.
Technical Fundamentals
 Application of technical fundamentals, by itself, is not enough
to create high productivity.
 Attention to development fundamentals is necessary but not
sufficient for achieving rapid development.
Technical Fundamentals
 Requirements Management
◦ Requirements management is the process of gathering requirements,
recording them, tracking the design and code against them, managing
changes to them for the rest of the project.
◦ Traditional requirements management practices are sometimes
considered as too rigid.
Technical Fundamentals
 Requirements management can provide great development-
speed mainly in 2 ways.
1. Requirements gathering done at a leisurely and then picking
up the pace without hurting quality.
2. Getting requirement right in the first place.
Technical Fundamentals
 Design
◦ Design serves as the foundation for construction, project scheduling,
project tracking, and project control.
◦ Effective design is essential to achieving maximum development
speed.
◦ By the time the project gets to construction, most of the groundwork
for project's success or failure has already been laid.
Technical Fundamentals
 Both requirements management and design offer greater
leverage on development schedule than construction does.
 In those activities, small changes can make a big difference in
schedule.
Technical Fundamentals
 Construction
 Construction might not offer many opportunities for large
reductions in schedule.
 But doing it correctly will save the waste of time.
◦ Wasting time gold-plating functions
◦ Debugging needlessly sloppy code
◦ Performance-tuning small sections of the system unnecessarily
Technical Fundamentals
 Poor design practices can force to rewrite major parts of
system; but poor construction practices won't force to do that.
 Poor construction practices can, introduce subtle errors that
take days or weeks to find and fix.
Technical Fundamentals
 Software Configuration Management (SCM)
◦ SCM is the practice of managing project artifacts so that the project
stays in a consistent state over time.
◦ SCM includes practices for
 evaluating proposed changes
 tracking changes
 handling multiple versions
 keeping copies of project artifacts
Technical Fundamentals
 Project artifact managed the most often is source code.
 But it is also possible to apply SCM to requirements, plans,
designs, test cases, problem reports, user documentation,
data, and any other work use to build the final product.
 Sometimes SCM can be implemented in a way that hurts
project efficiency.
Quality-Assurance Fundamentals
 When a software product has too many defects, developers
spend more time fixing the software than they spend writing
it.
 Some projects try to save time by reducing the time spent on
quality-assurance practices.
 Sometimes late running projects try to make up for lost time
by compressing the testing schedule.
Quality-Assurance Fundamentals
Quality-Assurance Fundamentals
 Error-Prone Modules
◦ An error-prone module is a module that is responsible for a
disproportionate number of defects.
◦ They tend to be more complex than other modules in the system, less
structured, and unusually large.
◦ They often were developed under excessive schedule pressure and
were not fully tested.
Quality-Assurance Fundamentals
 Modules with high defect rates are more expensive and time-
consuming to deliver than less error-prone modules.
 If development speed is important, make identification and
redesign of error-prone modules a priority.
 It will save time and improve the quality of the final product.
Quality-Assurance Fundamentals
 Testing
◦ Testing is finding errors by executing a program and seeing what it
does.
◦ Two basic kinds of execution testing are unit tests & system tests.
◦ Both types has a defect-detection rate is less than 60 percent.
◦ Remaining errors are found either by other error-detecting techniques
Quality-Assurance Fundamentals
 If testing discovers that the product's quality is too low,
product has to be delayed until it can be improved.
 Testing becomes the messenger that delivers bad news that
affects the schedule.
 Best way to leverage testing from a rapid development
viewpoint is to plan ahead for bad news
Quality-Assurance Fundamentals
 Technical Reviews
◦ Technical reviews include all kinds of reviews that are used to detect
defects in requirements, design, code, test cases, or other project
artifacts.
◦ Reviews vary in level of formality and in effectiveness.
◦ They play a more critical role in development speed than testing does.
Quality-Assurance Fundamentals
1. Walkthroughs
 Most common kind of review is probably the informal
walkthrough.
 Term walkthrough is loosely defined and refers to any
meeting at which two or more developers review technical
work with the purpose of improving its quality.
Quality-Assurance Fundamentals
 Walkthroughs are useful to rapid development, because it can
be use to detect defects well before testing in RAD.
 A walkthrough can detect a requirements defect at
specification time, before any design or code work is done.
 Walkthroughs can find between 30 and 70 percent of the
errors in a program.
Quality-Assurance Fundamentals
2. Code reading
 Code reading is a somewhat more formal review process than
a walkthrough.
 Applies only to code.
 Author of the code hands out source listings to two or more
reviewers.
 Reviewers read the code and report any errors to the author of
the code.
Quality-Assurance Fundamentals
3. Inspections
 Inspections are a kind of formal technical review.
 Developers play specific role during inspection.
 Moderator hands out the work product to be inspected before
the inspection meeting.
 Reviewers examine the work product before the meeting and
use checklists to stimulate their review.
Quality-Assurance Fundamentals
 During the inspection meeting, the author usually paraphrases
the material being inspected.
 Reviewers identify errors, and the document records the errors.
 After the meeting, the moderator produces an inspection
report.
 It describes each defect and indicates what will be done about it
Quality-Assurance Fundamentals
 Same as walkthroughs, inspections to can be used to detect
defects earlier with testing.
 Can be used to detect errors in requirements, user interface
prototypes, design, code, and other project artifacts.
 Inspections find from 60 to 90 percent of the defects in a
program, which is considerably better than walkthroughs or
testing.