IT3101RAD Lec5 BestPractices - Copy.docx

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


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


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


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


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


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/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)


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


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.


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.


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.


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.


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.

IT3101RAD Lec5 BestPractices - Copy.docx

Documents

Transcript of IT3101RAD Lec5 BestPractices - Copy.docx