Selection of an appropriate project

approach

Presented By:Shubham Aggarwal

Development of software in-house: The project team & the users of same

organization;

The application being considered slot into a portfolio of existing computer-based systems;

The methodologies & technologies to be used are not selected by the project manager, but are dictated by local standards.

Introduction:

An outcome of project analysis will be selection of the most appropriate methodologies & technologies.

Methodologies include techniques like OO development, SSADM and JSP.

Technologies might include an appropriate application-building and automated testing environment.

Choosing Technologies

The products and activities ,the chosen technology will influence:

1. The training requirement for development staff;

2. The types of staff to be recruited;3. The development environment-both

hardware and software;4. System maintenance arrangement.

Conti…

1. Identify project as either objective driven or product driven:

Often a product driven project will have been preceded by an objective driven project which choose the general software solution that is to be implemented.

Steps of Project Analysis

2. Analyse other project characteristics i. Is a data-oriented or process-oriented

system to be implemented? ii. Will the software that is to be produced be a general tool or application specific? iii. Is the application to be implemented of a

perticular type for which specific tools

have been developed?

Steps of project analysis

- Does it involve concurrent processing?- Will the system to be created be knowledge

based?- Will the system to be produced make heavy

use of computer graphics?

iv. Is the system to be created safety critical?v. What is the nature of the hardware/software environment in which the system will operate?

Conti…

3. Identify high level project risks: Uncertainty can be associated with a. Product: How well the requirements are understood? Some environments change so

quickly that a seemingly precise and valid statement of requirements rapidly becomes out of date.

b. Process: A new application building tool might be used. Any change in the way that the systems are developed introduces uncertainty.

c. Resource: The larger the number of resources needed or the longer the duration of the project, the more inherently risky it will be.

Steps of project analysis conti…

Some factors increase uncertainty, e.g. continually changing requirements, while other increase complexity, e.g. software size. Different strategies are needed to deal with the two distinct types of risks.

4. Take into account user requirements concerning implementation:

Unnecessary assumptions or constraints are not imposed on the way that a project’s objectives are to be met.

Conti…

5. Select general life-cycle approach Control systems Information systems General tools Specialized techniques Hardware environment Safety-critical systems Imprecise requirements.

Steps of project analysis conti…

Technical plan is likely to have following contents:-

Introduction and summary of contentsa) Character of the system to be developedb) Risk and uncertainties of the projectc) User requirements concerning

implementation Recommended approach

a) Selected methodology or process modelb) Development methodsc) Required software toolsd) Target hardware/software environment

Technical plan contents list

Implementationsa) Required development environmentb) Required maintenance environmentc) Required training

Implicationsa) Project products and activitiesb) Financial

In order to achieve an outcome, the system will have to execute one or more activities, that is its process.

To create a final product there are number of activities. These can be organized in different ways and we call these process models.

A major part of planning will be choosing development methods and slotting them into an overall process model.

Planner needs not only to select methods, but also to specify how each method is to be applied.

Choice of process models

Structure methods are made up of set of steps and rules to produce a final product.

Each of these products is documented, which is time consuming and implies some additional cost.

A response to this has been rapid application development(RAD).

RAD put emphasize on quickly producing prototypes of the software for users to evaluate.

Structure vs Speed of delivery

In RAD we use some structured methods and some other methods like joint application development(JAD).

In these workshops, developers and users work together for 3-5 days and identify and agree to business requirements.

These can speed up communication and negotiation.

What are “models”…????

Software process models are general approaches for organizing a project into activities.

◦ Help the project manager and his or her team to decide:- What work should be done;- In what sequence to perform the work.

◦ 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.

Also known as one-shot or once-through.

There are sequence of activities working from top to bottom.

The classic way of looking at S.E. that accounts for the importance of requirements, design and quality assurance.

The waterfall model

◦ 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.

The two key advantages of the waterfall model:

Identifying system requirements long before programming begins

It minimizes changes to the requirements as the project proceeds

The key disadvantages: The design must be completely specified on paper before programming begins

A long time elapses between the completion of the system proposal in the analysis phase and the delivery of the system (usually many months or years).

Users rarely are prepared for their introduction to the new system, which occurs long after the initial idea for the system was introduced.

If the project team misses important requirements, expensive post-implementation programming may be needed.

A system may require significant rework because of changes in business environment since the time the analysis phase occurred. It means going back to the initial phases and following the changes through each of the subsequent phases in turn.

It is the extension of waterfall model

The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.

The V-model deploys a well-structured method in which each phase can be implemented by the detailed documentation of the previous phase.

V-process model

verification and validation performed simultaneously.

save the time duration.

cost will be lesser.

Advantages

The customer is involved after end product is finished.

Any risk/contigencies are not analysed during the v- model

Disadvantages

It explicitly embraces prototyping and 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.

The spiral model

It promotes reuse of existing software in early stages of development. Allows quality objectives to be formulated during development. Provides preparation for eventual evolution

of the software product. Eliminates errors and unattractive alternatives early.

Advantages

Demands considerable risk-assessment expertise

It has not been employed as much proven models (e.g. the WF model) and hence may prove difficult to ‘sell’ to the client (esp. where a contract is involved)

that this model is controllable and efficient. [More study needs to be done in this regard]

Disadvantages

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 - different amounts of time to deliver; - differing amounts of effort.

The evolutionary model

Software prototyping A prototype is a working model of one or more aspects of

the project system.it is constructed and tested quickly and inexpensively in order to test out assumptions.

Prototypes can be classified as throw-away or evolutionary.

Throw-away prototypes:- Here the prototype is used only to test out some ideas and is then discarded when the true development of the operational system is commenced. The prototype could be developed using a different software environment or even on a different kind of hardware platform.

Evolutionary prototypes:-The prototype is developed and modified until it is finally in a state where it can become the operational system.In this case the standards that are used to devlop the software have to be carefully considered.

Some of the reasons that have been put forward for prototyping are the following

Learning by doing: When we have just done something for the first time we can usually look back and see where we have made mistakes.

Improved communication: Even if users do read system specification,they do not get a feel for how the system is likely to work in practice.

Improved user involvement: The users can be more actively involved in design decisions about the new system.

contd….. Clarification of partially known requirements: Where there is no existing system to mimic ,users can often get a better idea of what might be useful to them by trying out prototypes.

Demonstration of the consistency and completeness of a specification: Any mechanism that attempts to implement a specification on a computer is likely to uncover ambiguities and omissions.

  Reduced need for documentation: Because a

working prototype can be examined there is less need for detailed documentation of requirements.

contd….

Reduced maintenance costs: If the user is unable to suggest modification at the prototyping stage they are more likely to ask for changes to the operational system .This reduction of maintenance costs is the core of the financial case for prototypes.

  Feature constraint: If an application building tool is used

,then the prototype will tend to have features that are easily implemented by the tool.A paper based design might suggest features that are expensive to implement.

  Production of expected results: The problem with

creating test cases is generally not the creation of the test input but the accurate calculation of the expected results.A prototype can help here.

. 

Software prototyping is not without its drawbacks and dangers, however.

Users can misunderstand the role of the prototype: For example,they might expect the prototype to have as stringent input validation or a fast a response as the operational system although this was not intended.

  Lack of project standards possible: Evolutionary

prototyping could just be an excuse for a sloppy hack it out and see what happens approach.

Lack of control: It can be difficult to control the prototyping cycle if the driving force is the user propensity to try out new things.

Contd…. Additional expense : Building and exercising a

prototype will incur additional expenses.However,this should not be overestimated as many analysis and design tasks have to be undertaken whatever the approach. 

Machine efficiency: A system built through prototyping,while sensitive to the user’s needs,might not be as efficient in machine as one developed using more conventional methods.

Close proximity of developers: Prototyping could mean that code developers have to be sited close to the users.

Approach of breaking the system into small components which are then implemented & delivered in sequence.

Every iteration results in a release of a working system. Earlier iterations have less functionality than later ones, but the same high level of quality.

Alternatively referred to as Time Boxing, Evolutionary prototyping, Incremental Development & Iterative Development.

INCREMENTAL DELIVERY

INCREMENTAL DELIVERY WITH ITERATIONS

A six-month delivery cycle could be composed of 10 short iterations. The results of each iteration are not delivered to the marketplace, but the results of an incremental delivery are.

ITERATIVE DEVELOPMENT

Iterative and Incremental development is a cyclic software development process developed in response to the weaknesses of the waterfall model

Feedback from early increments can influence later stages.

Shorter time between design and delivery – possibility of change is not so great.

User benefits earlier Early delivery of some useful components

improves the cash flow. Smaller – easy to control and manage Project can be temporarily abandoned if more

urgent work crops up. Increased job satisfaction.

ADVANTAGES

Software Breakage – Later increments might require the earlier increments to be modified.

Developers might be more productive working on one large system than on a series of smaller ones.

DISADVANTAGES

1.Identify system objective:

- Gives the idea of ‘big picture’. - Individual requirement may change BUT

the objective should not.

2.Plan Increments

INCREMENTAL DELIVERY PLAN

Guidelines:

- Steps typically should consist of 1% to 5% of total project.- Non-computer function may be included.- Each increment should deliver some benefit to user.- Some increments will be physically dependent on

others.- Value to cost ratios may be used to decide priorities.

PLANING INCREMENTS

This is used to establish order in which increments are developed.

Based on customer & developer feedback on value & cost respectively.

Value to Cost Ratio

THANK YOU