it3101rad lec5 bestpractices - copy.docx
TRANSCRIPT
-
7/28/2019 IT3101RAD Lec5 BestPractices - Copy.docx
1/13
Best Practices
Overview
Best Practices (#27 identified examples)
Reduction of development schedules Reduction of perceived development schedules by making progress More visible Reduction of schedule volatility, thus reducing the chance of a runaway project Part III of Steve McConnells book Summaries the best practices in RADFor each Practice
Efficacy (Effectiveness/value)
Potential Reduction from Nominal Schedule
Improvement in Progress Visibility
Effect on Schedule Risk
Chance of Long term Success
Major Risks the risk of each practice posed on the project
Major interactions and Trade-Offs in using this practice
For each practice (contd.)Using Best Practice
Managing the Risks of Best Practice Side Effects of Best Practice
Best Practice's Interactions with Other Practices
The Bottom Line on Best Practice
Keys to Success in Using Best Practice
Change Board Daily Build and Smoke Test Designing for Change Evolutionary Delivery Evolutionary Prototyping Goal Setting Inspections Joint Application Development (JAD) Lifecycle Model Selection Measurement Miniature Milestones Outsourcing Principled Negotiation Productivity Environments
Rapid-Development Languages (RDLs) Requirements Scrubbing Reuse Signing Up Spiral Lifecycle Model Staged Delivery Theory-W Management Throwaway Prototyping Timebox Development Tools Group Top-10 Risks List User-Interface Prototyping Voluntary Overtime
-
7/28/2019 IT3101RAD Lec5 BestPractices - Copy.docx
2/13
Impact of Best Practices
Potential reduction from the nominal schedule
The effect of the best practice that will have on a project schedule
Improvement in progress visibility
Effects on schedule risk
E.g evolutionary prototyping, generally reduce development time compared with traditional
methods, but can make it more difficult to predict when the project will finish Chance of first time success
Some are more difficult than others to learn.
E.g reuse require substantial investment in infrastructure before they beginning to pay off.
Chance of Long term success
Major risk
Major interaction and Trade offs
How a particular best practice interacts with other Rapid Development practices, Some has no trade
offs while other requires more investment in money, sacrifice flexibility, or accept more risk to shorten
the schedule
Best Practices
All may not be used at once. May find some of them that can be practiced on your current projects without
radically changing altering the current approach being used
Summary of best practice Evaluation
-
7/28/2019 IT3101RAD Lec5 BestPractices - Copy.docx
3/13
1. Daily Build and Smoke Test
Daily build and smoke test : build the product and test it every day That means that every file is compiled, linked, and combined into an executable program every day.
The Product is then put through a "smoke test," a relatively simple test to see whether the product
"smokes" when you turn it on.
It minimizes integration risk It reduces the risk of low quality It supports easier defect diagnosis It supports progress monitoring It improves morale It improves customer relation
Build daily- The most fundamental part of the daily build is to build the product every day
Check for broken builds- In order for the daily-build process to be effective, the software that's built
has to work. If the software isn't usable, the build is considered to be broken, and fixing the build
becomes top priority.
At a minimum, a good build should:
Compile all files, libraries., and other components successfully
Link all files, libraries, and other components successfully
Not contain any showstopper bugs that prevent the program from being launched or that make it
hazardous to operate
Pass the smoke test
-
7/28/2019 IT3101RAD Lec5 BestPractices - Copy.docx
4/13
Smoke test daily. The smoke test should exercise the entire system from end to end. It does not have to bean exhaustive test, but it should be capable of detecting major problems.
Establish a build group. On most projects, tending the daily build becomes a big enough task that it needs
to be an explicit part of someone's job. On large projects, it can become a full-time job for more than one
person.
Daily Build and Smoke Test
Add code to the build only when It makessense to do so...
...but don't wait too long to add code to the build.
Require developers to smoke test their code before adding it to the system.
Create a holding area for code that's to be added to the build.
Create a penalty for breaking the build.
Release builds in the morning.
Build and smoke even under pressure.
What Kinds of Projects Can Use theDaily-Build-and-Smoke-Test Process?
Virtually any kind of project can use daily buildslarge projects, small projects, operating systems, shrink-wrap software, and business systems.
Keys to Success in Using theDaily Build and Smoke Test Here are the keys to success in using daily builds:
Build every day.
Smoke test every day.
Grow the smoke test with the product. Be sure that the test remains meaningful as the product evolves.
Make a healthy build the project's top priority.
Take steps to ensure that broken builds are the exception rather than the rule.
Don't abandon the process under pressure.
2. Joint Application Design
A Requirements definition and user interface design methodology with end users, executives anddevelopers to meet and develop systemsdetails
JAD generally focuses on business details rather than technical details It is most applicable to the development of business systems, but it can be used successfully for shrink-
wrap and systems software.
Shorten schedule through gathering requirements effectively Its success depends on effectiveness of JAD leadership in JAD sessions, participation of key end users,
decision makers and developers JAD is one of the most powerful requirements-specification practices yet developed, and it produces its
savings in several ways.
It commits top executives to the software-planning processIt shortens the requirements-specification phaseIt eliminates features of questionable valueIt helps to get requirements right the first timeIt helps to get the user interface right the first time.It reduces organizational infighting(any conflicting objectives and hidden agendas brought to light early
and addressed them effectively) Potential risks
Unrealistic productivity expectations following the JAD sessions
Premature, inaccurate estimates of remaining work
Major Interactions and tradeoffsWorks well with incremental development
-
7/28/2019 IT3101RAD Lec5 BestPractices - Copy.docx
5/13
JAD
JAD consist of two phasesJAD Planning phase
JAD Design Phase
JAD Planning the emphasis is on mapping out broad capabilities of the software system. The emphasis is more on
business concerns than detailed technical concerns.
The main outcomes of the JAD-planning phase are the system's goals, preliminary effort and schedule estimates, and a decision about whether to
continue with further product development.
JAD planning also sets up the JAD-design phase.JAD
JAD design
elicits more detailed requirements, and its purpose is to create the user-level design of the software. In spite of being called "design," it does not focus on the functional design of the
system, which is what you might think of when you think of "design." JAD design uses prototyping extensively, and the main outcomes of this phase are a detailed user-interface
design, a database schema (if appropriate), and refined budget and schedule estimates.
At the end of this phase, the project must again be approved before it can continue.Different models available for JAD
JAD Process
1. CustomizationThe session leader and perhaps a few other people take the out-of-the-box JAD
methodology and tailor it to the specific project. This typically requires from 1 to 10 days.
2. SessionThe session, the time when all the parties are brought together, is the main focus of
JAD. It typically lasts from 1 to 10 days, depending on the size of the system.
3. Wrap-upWrap-up is the documentation or packaging of the session activity. Handwritten notes and visual
aids are converted into one or more formal documents. This takes from 3 to 15 days.
Should JRP and JAD be separate?
Sometimes combined and some time separate
Joint Requirements Planning (JRP) istechnical detail usually shorter duration and without
Sometimes held with the top management
JRP session establishes the requirements, justification for a system and the detailed functions
JAD establishes the design aspects of the system
-
7/28/2019 IT3101RAD Lec5 BestPractices - Copy.docx
6/13
Benefits of JRP
Links system planning to the top level analysis of goals, problems, critical success factors and strategicplanning
Encourages brainstorming of what the most valuable system functions are likely to beBenefits and features ofJAD sessions
JAD sessions take shorter periods than traditional methods Harnesses end users to design process and helps avoid dissatisfaction Eliminates paper specifications with a prototype Results in increased user satisfaction as users get involved in design process; feels ownership and help in
construction process
JAD- session
TimelineJAD session can last anywhere from 1 to 10 days.JAD is a team activity, so typical teamwork guidelines apply.It usually takes 2 days for a JAD team to jell (Martin 1991). If the JAD session lasts 5 days, the team will
do most of its work on days 3, 4, and 5.
Regardless of the duration of the JAD session, the participants must attend full-time. If some participantsattend only part-time, you waste time briefing them and re-covering old ground.
To achieve the group synergy of a JAD session, all group members need to be present. Facilities
The JAD room is located off-site, ideally in a hotel or conference facility.JAD participants are normally key people in the organization, and key people usually have dozens of
potential distractions.
The facility should free participants from their normal distractions and allow them to focus exclusively onthe JAD session.
Allowing participants to respond to interruptions during a session suggests that the JAD session isn'timportant.
The JAD room for both planning and design should include visual-aid support, computer support, copymachine, notepads, pens, Polaroid camera to record whiteboard contents, name cards (if needed), and
drinks and refreshments.
This combination of facilities sends an important message to the JAD participants: "This job is important,and the organization is behind you."
Roles- JAD session include a number of peopleSession Leader/Workshop LeaderExecutive Sponsor(s)person who bear the financial responsibility for the system/ Focal point for go/no-
go decision that follows the session
End-user representativeperson with authority, a good communicatorDeveloper(s)person who helps end user to steer away from specifying a blue sky- a system that is
not implementable and to learn end users perspective.
Scribes/w developer who record minutes of the session. Asks clarifications and points outinconsistencies
Specialistsexperts
-
7/28/2019 IT3101RAD Lec5 BestPractices - Copy.docx
7/13
Role of Workshop leader
Qualities?
Excellent communication and mediation skills Impartial, unbiased, neutral personality Good negotiating skills is a must. Sensitive to corporate politics, diplomatic Good at conducting meetings, meeting leaderships qualities- moderator! Understand group dynamics and making the issues interesting and getting them work harder in areas
that need detailing
Capable of organizing the research, documents and people Familiar with diagramming and prototyping tools used in the workshopsi.e he/she has to be a
technical manager
Common Problems- JAD
Some organizations do not spare time of star performers. If key people do not participate, do not do thesession at all
Observers are a risk at JAD sessions Too many participants. Typically 8 or less is better. In some cases around 15?The Process during a JAD session
Conducting the orientationintroduce the group to the purpose of the session, time table, agenda. Defining high-level requirements. Identification of business needs, system objectives, anticipated benefits, list of possible functions, rough
prioritization of functions, strategic and future considerations.
Limiting the system scope. Place limits on what the system can include Identifying and estimating the JAD design phases. Follow-on JAD activities Identifying JAD design participantspeople who will take part in follow-on sessions Documenting the issues and considerations Conclusions
Typical outputs of a JRP workshop
List of depts served by the system List of systems objectives Possible system functions
List of possible systems functions List of benefits of each functions Prioritization of functions
Process decomposition diagram of the system Process flow diagram List of unresolved issues
Details of the unresolved issue Responsibility and deadline
Implementation target date(s)
-
7/28/2019 IT3101RAD Lec5 BestPractices - Copy.docx
8/13
3. Time Boxed Development
Construction time practice that helps infuse a development team a sense of urgency and helps team tofocus on most important features.
Saves time by redefining the product to fit the schedule rather than redefining the schedule to suit theproduct
Most applicable to in-house development but can be adopted for the use on others too. Success depends on the kind of projects and clients willingness to reduce feature rather than stretch
schedule.
Timeboxing is usually applied to design and construction phase Timeboxing can be applied parts of systems development, prototypes or throw away prototypes Can be applied to software construction, help screen generation, user documentation, throw away
prototyping, training course development
Major Risks: Attempting to time box unsuitable work products Sacrificing quality instead of features
Interactions and Trade-offs Depends on the use of Evolutionary Prototyping Trades feature-set control for development time control Often combined with JAD, CASE tools and Evolutionary Prototyping on RAD projects Can be Combined with Evolutionary Delivery
Emphasizes the priority of schedule It is important to build a basic version working rather than a feature rich version Clarifies feature priorities Limits developer on gold plating: Same feature can be developed in different ways (same features can be
developed as several versions ->2 day, 2 week, 2 month version)
Controls feature creep : Due to tight schedule team has less time for lobbying for new features. Due toshortened schedule market or operational changes ( business environmental changes) are less
Suitability Criteria Time box development is not suited for all kinds of projects
Priorities list of features Identify minimal core feature set and time box
Realistic estimates created by the time box team Estimate should be created by the team. Developers are not pressed for an unrealistic combination of schedule and functional goals
Right Type of Project Best suited for inhouse development. Highly custom development that require hand crafting maynot be the best.
Sufficient end user involvement Quality?
Limited functionality does not mean limited quality Who decides on estimates?
Team makes the resource estimation There should not be pressure to meet
impossible deadlines
-
7/28/2019 IT3101RAD Lec5 BestPractices - Copy.docx
9/13
Time boxing - Prioritization
It is sometimes difficult to priorities the requirements All the requirements are important for the final system but not the same extent. if the full set can not be addressed within the timebox, then the MoSCoW categorization can be used to
focus on the requirements appropriately
MoSCoW rules
One approach isto apply MoSCoW rules
Must. Should. Could..WantMust - crucial requirements. If omitted the system will not operateShould - are important, but the system will operate without themCould- less important and less beneficial to the userWant- want to have but will not have at this time around can be left for a later increment
Parallel Development Usually multiple time boxes exists in one project A complex application can be sub-divided in to sub systems Subsystems- Desirable features?
Performs independent functions Can be tested on its own Can be test for usability Data flow among components are as little as possible
4. Outsourcing Outsourcing is the practice of paying an outside organization to develop a program instead of developing it
in-house.
Outsourcing companies can have more expertise in an applications area, more developers available to workat a given time, and a larger library of reusable code to draw from.
The combination can result in a dramatic reduction in the time needed to deploy a new product. In some instances, Outsourcing can save development cost, too. Reasons that outsourcing can save time
Reuse Staffing flexibility Experience Better requirement specification Reduce feature creep
Using Outsourcing
Organizations sometimes turn to outsourcing because they are frustrated by the difficulties of managingin-house software development.
They assume that if someone else builds the software for them, their job will be much easier. But the reality is almost the opposite. You have less visibility into the project's progress when it is being
conducted across town or across the globe, and compensating for that lack of visibility requires astute and
attentive management.
As a rule, Outsourcing requires even more skillful management than in-house development.
-
7/28/2019 IT3101RAD Lec5 BestPractices - Copy.docx
10/13
When you Outsource
Develop a management plan including risk management. Learn about contract management. Make communication with the vendor a priority Count on using some of your own technical resources Be leery of unstable requirements
Retain enough control to pull the work back in-house if needed. Especially consider outsourcing legacy-systems reengineering. Avoid double standards for outsourced work
Offshore Outsourcing
One of the outsourcing options that's become increasingly popular is offshore outsourcing. Offshore companies offer lower labor costs than you might find locally Several issues
Communication Time differences Travel Characteristics of vendors country
Risk of outsourcing
Loss off visibility Transfer of expertise outside your organization Loss morale Loss of control over future programs Compromise of confidential
Side effect of outsourcing
Welcome relief Reduced manpower fluctuations
Keys to success in using outsourcing
Select the Outsourcing vendor carefully. Craft the contract with the vendor carefully. Plan to manage the outsourced project at least as carefully as you would an in-house project. Make communication with the vendor a priority, both electronically and in person.
5. Throwaway prototyping
With Throwaway Prototyping, code is developed to explore factors critical to the system's success, andthen that code is thrown away.
The prototyping implementation uses programming languages or development practices or both that aremuch faster than the target language and practices.
The user interface is prototyped far more commonly than any other part of the system, but other parts ofsome systems can also benefit from being prototyped.
-
7/28/2019 IT3101RAD Lec5 BestPractices - Copy.docx
11/13
Using throwaway prototyping
Throwaway Prototyping can be used by any of the project's personnel. Individual project participants canrealize some benefit by prototyping risky areas within their individual areas of responsibility.
Here is a list of areas that can benefit from being prototyped and suggestions about how to developprototypes in those areas cheaply:
User interfacePrototype using a prototyping tool or visual programming language, or build aHollywood facade in the target programming language.
Report formatsPrototype using a word processor or report formatting tool. Graph formatsPrototype using a drawing tool or graphics library. Database organizationPrototype using a database design language, 4GL, or CASE tool. : Database performancePrototype using a database design language, 4GL, or CASE tool.
Accuracy and implementation of complex calculationsPrototype using a spreadsheet or math-oriented language such as API.
Time-critical parts of real-time systemsPrototype using a small test program in the targetprogramming language.
Performance of interactive systemsPrototype using a small test program in the target programminglanguage.
Feasibility of parts of the system that are pushing the state-of-the-art or with which the developmentstaff has no experiencePrototype using a visual programming language, small test program in the
target programming language, or math-oriented languagewhatever is appropriate.
Managing the Risks of Throwaway Prototyping
Keeping a throwaway prototype
Inefficient use of prototyping time.
Unrealistic schedule and budget expectations
Side Effects of ThrowawayPrototyping
In addition to its rapid-development benefits, Throwaway Prototyping produces many side effects, most
of which are beneficial. Prototyping tends to:
Reduce project risk (since you explore risky implementation areas early) Improve maintainability Provide resistance to creeping requirements Provide a good opportunity to train inexperienced programmers since the code they write will be thrown
away anyway
Keys to Successin Using Throwaway Prototyping
Choose your prototyping language or environment based on how quickly it will allow you to createthrowaway code.
Be sure that both management and technical staffs are committed to throwing away the throwawayprototype.
Focus prototyping efforts on areas that are poorly understood. Treat prototyping activities as scientific experiments, and monitor and control them carefully.
-
7/28/2019 IT3101RAD Lec5 BestPractices - Copy.docx
12/13
6. Evolutionary prototyping
Evolutionary Prototyping is a lifecycle model in which the system is developed in increments so that it canreadily be modified in response to end-user and customer feedback.
Most evolutionary-prototyping efforts begin by prototyping the user interface and then evolving thecompleted system from that, but prototyping can start with any high-risk area.
Evolutionary Prototyping is not the same as Throwaway Prototyping, and making the right choice aboutwhether to develop an evolutionary prototype or a throwaway prototype is one key to success.
Other keys to success include using experienced developers, managing schedule and budget expectations,and managing the prototyping activity itself.
Evolutionary Prototyping is a development approach in which you develop selected parts of a system firstand then evolve the rest of the system from those parts. Unlike other kinds of prototyping, in Evolutionary
Prototyping you don't discard the prototyping code; you evolve it into the code that you ultimately deliver.
Evolutionary Prototyping supports rapid development by addressing risks early. You start development with the riskiest areas of your system. If you can overcome the obstacles, you can
evolve the rest of the system from the prototype.
If you can't, you can cancel the project without having spent any more money than necessary to discoverthat the obstacles were insurmountable.
Using Evolutionary prototyping
Evolutionary Prototyping is an exploratory activity that you use when you don't know at the outset exactlywhat you need to build.
two main options are to start with the most visible parts or the riskiest parts. The user interface is often boththe most visible and the riskiest part, so it is often the obvious place to start.
After you've built the first part of the system, you demonstrate it and then continue to develop the prototypebased on the feedback you receive.
If your prototyping effort is customer-oriented, you'll continue to solicit feedback from the customer and torefine the user interface until everyone agrees that the prototype is good enough.
Then you develop the rest of the system using the prototype's design and code as a foundation. You can use Evolutionary Prototyping to greater or lesser degrees on most kinds of projects. It is probably best suited to business systems in which developers can have frequent, informal interactions
with end-users.
But it is also well suited to commercial, shrink-wrap, and systems projects as long as you can get end-users involved.
-
7/28/2019 IT3101RAD Lec5 BestPractices - Copy.docx
13/13
Managing the Risks of Evolutionary Prototyping Unrealistic schedule and budget expectations Diminished project control Poor end-user or customer feedback Poor product performance Unrealistic performance expectations Poor design Poor maintainability Feature creep. Inefficient use of prototyping time
Side Effects of Evolutionary Prototyping
In addition to its rapid-development benefits, Evolutionary Prototyping produces many side effects, mostof which are beneficial.
Prototyping tends to lead to: Improved morale of end-users, customers, and developers because progress is visible Early feedback on whether the final system will be acceptable Decreased overall code length because of better designs and more reuse Lower defect rates because of better requirements definition Smoother effort curves, reducing the deadline effect (which is common when using traditional
development
Keys to Success in Using Evolutionary Prototyping
Decide at the beginning of the project whether to evolve the prototype or throw it away. Be sure thatmanagers and developers are both committed to whichever course of action is selected.
Explicitly manage customer and end-user expectations having to do with schedule, budget, andperformance.
Limit end-user interaction with the prototype to controlled settings. Use experienced developers. Avoid using entry-level developers. Use design checklists at each stage to ensure the quality of the prototyped system. Use code-quality checklists at each stage to ensure the maintainability of the prototyped code. Consider performance early. Carefully manage the prototyping activity itself. Consider whether Evolutionary Prototyping will provide the most benefit or whether Evolutionary
Delivery or Staged Delivery would be better.