Rapid Development Strategy – Lecture 03

Outline:
 Avoiding Classic mistakes
- People related
- Technology related
- Product related
- Process related
 Applying Software development fundamentals
- Management fundamentals
- Technical fundamentals
- QA fundamentals
 Risk Management
- Element of Risk Management
- Risk Identification
- Risk Analysis
- Risk Prioritization
- Risk Control
 Schedule-oriented practices

General Strategy for rapid development

The four pillars of rapid development. The best possible schedule depends on classic-mistake
avoidance, development fundamentals, and risk management in addition to the use of schedule-
oriented practices.

Classic Mistakes in RAD

People-related classic mistakes
Undermined motivation
suspicious talks at the beginning, asking to work overtime reduces the motivation.
team leaders take long vacations while the team is working overnights.
The team lead has to work along with other team members is a positive motivation.
Weak personnel
an efficient development, the recruitment needs to hire talented developers. carefully filter
people who could do most of the work until the end of the project.
Uncontrolled problem employees
Failure to take action for problems with team members and team leads.
Some higher management should actively look into those and sort them out.
Heroics
Heroics within the team increases the risk and discourages cooperation among the other
members of the team
Adding people to a late project:
Adding new people when the project is behind schedule, can take more productivity away
from team members.
Noisy, crowded offices
Friction between developers and customers:
Need to increase the communication between customers and developers.
Unrealistic expectations:
Setting deadlines earlier without any proper reasons can lengthen the development
schedule.
Lack of effective project sponsorship:
project sponsorship is necessary to support many aspects of rapid development, including
realistic planning, change control, etc.

Technology related mistakes

This type of mistake is about technologies used during the project.
Silver-bullet syndrome
Thinking that a certain approach will solve every issue, and that approach has not already
been used by developers (e.g.: Object-oriented design)
Overestimated savings from new tools or methods
New practices will introduce a new risk as the team has to go through a learning curve to
become familiar.
Switching tools in the middle of a project
Using new tools will add a learning curve, rework, and inevitable mistakes to the project
schedule
Lack of automated source-code control
If two or more developers are working on the same part of the project, it is necessary to
adhere to source-code control practices.
If not developers have to spend time resolving conflicting changes.

Process related
Overly optimistic schedules:
This sort of schedule will fail by under-scoping the project and hurt the long-term morale
and productivity of the developers.
Insufficient risk management:
If project risks are not actively managed, the project will lead into a slow-development
mode.
Contractor failure:
weak relationship with contractors can lead to a slow-down in the project
Insufficient planning
Short-changed upstream activities:
Starting coding without properly designing the project plans will cost 10 or 100 times more
than doing it with properly designed plans.
Short-changed quality assurance
Eliminating design and code reviews, eliminating test planning, and doing only perfunctory
testing will reduce the development of the project and ends up with major bugs.
Omitting necessary tasks from estimates
People forget about the less visible tasks and those tasks add up.
Code-like-hell programming
Developers should be sufficiently motivated rather forcing them to work hard.

Product related
This type of mistake talks about which can affect the outcome of the project.
Requirements gold-planting:
More requirements that are not necessary, and pay less attention to complex features
Feature creep:
On average 25% of requirements can be changed and affect the project schedule.
Developer gold planting:
Frequently, developers attempt to try new technologies that they saw in other projects,
which is not necessary.
 Applying Software development fundamentals
1. Management fundamentals
Estimation and Scheduling: Accurate estimation is an essential input for effective planning,
which is essential for efficient development.
Planning: work for not to face a poor planning
Tracking: progress tracking, status meetings, status reports, milestone reviews, budget reports,
and management by walking around.
Measurement: used to analyze status, quality, and productivity using metrics including how
much or how little data to collect and how to collect it.

2. Technical Fundamentals
Design:
 Major design styles practices (such as object design, structured design, and data structure
design)
 Foundational design concepts (such as information hiding, modularity, abstraction,
encapsulation, cohesion, coupling, hierarchy, inheritance, polymorphism, basic algorithms,
and basic data structures)
  Standard design approaches to typically challenging areas (including exception handling,
internationalization and localization, portability, string storage, input/output, memory
management, data storage, floating-point arithmetic, database design, performance, and
reuse)
 Design considerations unique to the application domain you’re working in (financial
applications, scientific applications, embedded systems, real-time systems, safety-critical
software, or something else)
 Architectural schemes (such as subsystem organization, layering, subsystem
communication styles, and typical system architectures)
 Use of design tools

Requirement management:
 Requirements-analysis methodologies including structured analysis, data structured
analysis, and object-oriented analysis
 System-modeling practices such as class diagrams, dataflow diagrams, entity-relationship
diagrams, data-dictionary notation, and state transition diagrams
 Communication practices such as Joint Application Development (JAD), user-interface
prototyping, and general interview practices
 The relationships between requirements management and the different lifecycle models
including evolutionary prototyping, staged releases, spiral, waterfall, and code-and-fix

Construction:
 Coding practices (including variable and function naming, layout, and documentation)
 Data-related concepts (including scope, persistence, and binding time)
 Guidelines for using specific types of data (including numbers in general, integers, floating-
point numbers, characters, strings, Booleans, enumerated types, named constants, arrays,
and pointers)
 Control-related concepts (including organizing straight-line code, using conditionals,
controlling loops, using Boolean expressions, controlling complexity, and using unusual
control structures such as go to, return, and recursive procedures)
 Assertions and other code-centered error-detection practices
 Rules for packaging code into routines, modules, classes, and files
 Unit-testing and debugging practices

Software configuration management:

 includes practices for evaluating proposed changes, tracking changes, handling multiple
versions, and keeping copies of project artifacts as they existed at various times.
 The project artifact managed the most often is source code, but you can apply SCM to
requirements, plans, designs, test cases, problem reports, user documentation, data, and
any other work you use to build your product.
 evenly used SCM in writing this book because not using it in my last book caused too many
problems.
 3. QA fundamentals
Relationship between defect
rate and development time.
In most cases, the projects
that achieve the lowest defect
rates also achieve the
shortest schedules.

Error-Prone Modules:
 Error-prone modules 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.
 If a module’s error rate hits about 10 defects per 1000 lines of code, review it to determine
whether it should be redesigned or re-implemented
Testing:
 The most common quality-assurance practice is undoubtedly execution testing, finding
errors by executing a program and seeing what it does.
 The two basic kinds of execution testing are unit tests, in which the developer checks his or
her code to verify that it works correctly, and system tests, in which an independent tester
checks to see whether the system operates as expected.
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 ineffectiveness, and they play a more critical role in
development speed than testing does.
 The following sections summarize the most common kinds of reviews.
Walkthrough:
 The term “walkthrough” is loosely defined and refers to any meeting at which two or more
developers review technical work to improve its quality.
 Walkthroughs are useful for rapid development because you can use them to detect defects
well before testing.
 The earliest time that testing can detect a requirements defect
Code reading:
 formal review process than a walkthrough but nominally applies only to code.
 In code reading, the author of the code hands out source listings to two or more reviewers.
(more effective rather than individuals)
 The reviewers read the code and report any errors to the author of the code.
Inspection:
 Inspections are a kind of formal technical review that is extremely effective in detecting
defects throughout a project.
 Inspections, developers receive special training in inspections and play specific roles during
the inspection.
 The “moderator” hands out the work product to be inspected before the inspection meeting.
 The “reviewers” examine the work product before the meeting and use checklists to
stimulate their review
Comment on technical reviews

Managing Risks
Elements of risk management
The job of software risk management is to identify, address, and eliminate sources of risk before
they become threats to the successful completion of a software project.
You can address risks at any of several levels.

Levels of Risk management

1. Crisis management—Firefighting; address risks only after they have become problems.
2. Fix on failure— Detect and react to risks quickly, but only after they have occurred.
3. Risk mitigation—Plan ahead of time to provide resources to cover risks if they occur, but do
nothing to eliminate them in the first place.
4. Prevention—Implement and execute a plan as part of the software project to identify risks
and prevent them from becoming problems.
5. Elimination of root causes—Identify and eliminate factors that make it possible for risks to
existing at all
The purpose of the topic is to describe how to address software schedule risks at levels 4 and 5
rather than at levels 1 through 3.

Risk Assessment
Risk assessment is made up of risk identification, risk analysis, and risk prioritization:

 Risk identification: produces a list of risks that have the potential to disrupt the project’s
schedule.
 Risk analysis: assesses the likelihood and impact of each risk and the risk levels of
alternative practices.
 Risk prioritization: produces a list of risks prioritized by impact. This list serves as a
basis for risk control.

Risk Control
Risk control is made up of risk-management planning, risk resolution, and risk monitoring:
  Risk-management planning produces a plan for dealing with each significant risk. It
also makes sure that the risk-management plans for each of the individual risks are
consistent with each other and with the overall project plan.
 Risk resolution: is the execution of the plan for dealing with each significant risk?
 Risk monitoring: is the activity of monitoring progress toward resolving each risk item?
Risk monitoring can also include the ongoing activity of identifying new risks and feeding
them back into the risk-management process.

Risk identification
 Organization and management risks
 Development environment risks
 End user’s risks
 Customer risks
 Contractors risks
 Requirements risks
 Product risks
 External environment risks
 Personnel risks
 Design and implementation risks
 Process risks

Risk Analysis
After you’ve identified the risks to your project, the next step is to analyze each risk to determine
its impact.

 Risk Exposure
Risk exposure is equal to the probability of the unexpected loss multiplied by the size
of the loss.
 Estimating Size of Loss
break down the loss into smaller losses, estimate those, and then combine the
individual estimates into an aggregate estimate.
 Estimating Probability of Loss
estimations done by a person who most familiar with the system estimate the
probability of each risk,

Risk Prioritization
Once you’ve created the list of schedule risks, the next step is to prioritize the risks so that you
know where to focus your risk-management efforts.
risk-assessment table sorted by risk exposure.
Risk Control
Risk-Management Planning
to develop a plan to handle each of the high-priority risks identified during the previous activities.
The risk management plan describes who, what, when, where, why, and how of each risk’s
management.
It should also contain general provisions for monitoring the risks, closing out risks that have been
resolved, and identifying emerging risks.
Risk Resolution
Risk dependencies between another risk.
Risk Monitoring
risk-monitoring tools is the use of a “Top-10 Risks” list that you create. The Top-10 list contains
each risk’s current rank, its previous rank, the number of times it has been on the list, and a
summary of steps taken to resolve the risk since the previous review.
Interim Postmortems
the Top-10 list is probably the most useful risk-monitoring practice, a fast-track project should
also include postmortems conducted throughout the project.
Risk Officer
The job of the risk officer is to be alert to risks to the project and to keep managers and developers
from ignoring them in their planning.