+ All Categories
Home > Technology > Software lifecycle model report

Software lifecycle model report

Date post: 10-May-2015
Category:
Upload: ashutosh-singh
View: 1,745 times
Download: 2 times
Share this document with a friend
Popular Tags:
21
Classification of Software Projects On the Basis Of Its Features and Then Suggesting Appropriate Life Cycle Model Based on the Features Department of Electronics and Computer Engineering Indian Institute of Technology Roorkee Under Guidance of:Dr. Sandeep Kumar Garg Vikas Yadav 10114046 Pawan Kumar 10114031 Chirag Kothari 10114014 Ashutosh Singh 10114010 Udit Panesar 10114044 2012
Transcript
Page 1: Software lifecycle model report

Classification of Software Projects On the Basis

Of Its Features and Then Suggesting Appropriate

Life Cycle Model Based on the Features

Department of Electronics and Computer Engineering

Indian Institute of Technology Roorkee

Under Guidance of:Dr. Sandeep Kumar Garg

Vikas Yadav

10114046

Pawan

Kumar

10114031

Chirag

Kothari

10114014

Ashutosh

Singh

10114010

Udit Panesar

10114044

2012

Ashu
Stamp
Page 2: Software lifecycle model report

Introduction Software engineering is the application of a systematic, disciplined, quantifiable approach to

the design, development, operation, and maintenance of software, and the study of these

approaches, that is, the application of engineering to software. There was no software

engineering some years back.Softwares were being developed, coded and implemented

through mere intuition and trial and error approach. Gradually Software Engineering has

evolved from an art and taken the form of an engineering methodology .There are different

approaches to develop software s by following different paradigms and processes . Work is

divided at coded implemented ,designed and delivered finally.Many different methods have

come up for the development of softwares depending upon the problem size , cost and

complexity, also called Life Cycle Models. They provide a fixed generic framework that can

be tailored to a specific project. Each model has its advantages as well as disadvantages. To

identify which model is appropriate for the given project, we classify the project on the basis

of its features. Feature is an intentional distinguishing characteristic of a software item. Then

depending upon the features we decide which model is appropriate for the given project. The

features are decided not only by the project which means what to do, it also depends upon the

company or the workforce doing the project and also on user side needs and requirements

like complete delivery at the end or delivery in stages.

Software project classification:

Based on the different features of the project or the software being developed ,software projects

can be classified into many classes. To develop quality softwares successfully and systematically,

different methodology is followed for different types of projects depending upon their different

features. The different identifiable characteristics of the projects are as listed below:-

1. Risk

2. Approximated time

3. Size and Cost

4. Experience of members

5. Stability

6. Complexity

7. Maintenance Requirements

8. Reusability

9. User involvement

10. Requirement specification

11. Changes incorporated

12. Resources prediction

13. Documentations

14. Organization structure

Page 3: Software lifecycle model report

Now, there are many Life Cycle Models. Here we have thrown light over some of the

prominent models used in the industry

V DEVELOPMENT MODEL

Overview

The V model is a basic Software Development Model, which is sometimes also referred as an

extension of the classical waterfall model.The mai difference being that instead of moving in

a linear way the steps are bent upwards after the coding phase to form a V shape , as shown

in the diagram at the bottom. In the V model there is a link between the phases present in the

two arms of the V .But this doesn’t mean that it is not a sequential process. It is a sequential

path of execution of processes. Each phase must be completed before the next starts. The

horizontal axis represents time of the completion of the project and the vertical axis

represents the level of abstraction, coarsest grain abstraction being the uppermost.

Testing is emphasized in this model more so than the waterfall model though. The testing

procedures are developed early in the life cycle before any coding is done, during each of the

phases preceding implementation. Requirements mark the beginning of the life cycle model

just like the waterfall model. A test plan is made before starting the project. The test plan

focuses on meeting the functionality specified in the requirements gathering. The high-level

design phase focuses on system architecture and design.In the low-level design phase, the

actual software components are designed, and unit tests are created.Coding takes place in the

implementation phase. As the coding gets completed the path of execution changes direction

and now starts moving up the V where the test plans which were made earlier are put into

use. A Generalized diagram of the model is shown below:

Project Planning and Requirements– allocate resources

Product Requirements and Specification Analysis – complete specification of the

software system

Architecture or High-Level Design– defines how software functions fulfill the design

Detailed Design – develop algorithms for each architectural component

Production, operation and maintenance – provide for enhancement and corrections

System and acceptance testing –check the entire software system in its environment

Integration and Testing – check that modules interconnect correctly

Unit testing – check that each module acts as expected

Page 4: Software lifecycle model report

Coding – transform algorithms into software

PROTOTYPING MODEL

Journey of the prototyping :-

THROWAWAY PROTOTYPING MODEL

Page 5: Software lifecycle model report

With 'throw-away' prototyping prototype for a small portion of the system is developed and then

given to the end user to test and evaluate. The user provides feedback which can quickly be followed

and incorporated into the development of the system. The prototype is then thrown away or discarded.

This is very different to the evolutionary approach.

There are many situations in which user’s end requirements are not clearly specified. This model

fulfils the objective of validating the requirements are validated and clearly understood. The approach

is to construct a quick and dirty partial implementation of the system during or before the

requirements phase.

Main benefits :Used in making projects that have low risk in such areas as losing budget, schedule

predictability and control, large-system integration problems, or coping with information sclerosis,

but high risk in user interface design.

Main risks:Use in projects that have low risk in such areas as losing budget, schedule predictability

and control, large-system integration problems, or coping with information sclerosis, but high risk in

user interface design.

Advantages:

1. This model significantly reduces the project risks.

2.The projects formed through this model have a short life span.

Disadvantages:

1.The prototype basically does nothing. It is just presentational.

2.This model can be employed only for limited purposes.

EVOLUTIONARY PROTOTYPING MODEL

The idea behind this is that an initial prototype is presented to the user. They provide feedback and

suggestions for improvements. These are acted upon by the developer who then presents a more

refined prototype. The user once more provides feedback. The process is repeated.

So at each stage the prototype 'evolves' towards the final system.

Hence the term 'evolutionary prototyping'.

Advantages:

1.This model helps to speed up the delivery of the system .

2.This model also allows a lot of user interaction.

3. The system meets up to the user requirements.

Disadvantages:

Page 6: Software lifecycle model report

1. A problem with evolutionary prototyping is knowing when it is necessary to stop tweaking the

system and actually finish the development.

2. Long term maintenance can be expensive.

Use in projects that have low risk in such areas as losing budget, schedule predictability and control,

large-system integration problems, or coping with information sclerosis, but high risk in user interface

design.

EXTREME PROGRAMMING Extreme programming is very far from difficult ,large or complex projects .Extreme

Programming, also called XP, is a lightweight method of software development based on

principles of communication ,simplicity, courage and feedback . XP is designed for small

teams who need to build the software quickly in an environment of rapidly-changing

re-quirements . It works by bringing the whole team together in the presence of simple

practices, with required feedback to enable the team to see where they stand and to modify

the practices according to their unique situation.

Extreme Programming can be summed up into twelve practises:

The Planning Process

The XP planning process allows the XP customer to set and define the business value

of desired features, and uses cost estimates provided by the coders to choose what needs to be

done and what not. The effect of XP’s planning process is that it is easy to propell the project

to success.

Small Releases

XP teams put a simple system into production early, and update it frequently

through a very short cycle.This is repeated for many iterations.

Metaphor

XP teams use a common “system of names” and a common system description

that guides development and communication.

Simple Design

A program built with XP should be the simplest program and it should meet the current

requirements.There is not much building for the future”. Instead, the focus is

on providing business value. Of course it is necessary to ensure that you have a

good design, and in XP this is brought about through “refactoring”, discussed

below.

Page 7: Software lifecycle model report

Testing

XP teams focus on validation of the software at all times. Programmers de-

velop software by writing tests first, then software that fulfills the requirements

reflected in the tests. Customers provide acceptance tests that enable them to

be certain that the features they need are provided.

Refactoring

XP teams improve the design of the system throughout the entire development.

This is done by keeping the software clean: without duplication, with high

communication, simple, yet complete.

Pair Programming

XP programmers write all production code in pairs, two programmers working

together at one machine. Pair programming has been shown by many exper-

iments to produce better software at similar or lower cost than programmers

working alone.

Collective Ownership

All the code belongs to all the programmers. This lets the team go at full speed,

because when something needs changing, it can be changed without delay.

Continuous Integration

XP teams integrate and build the software system many times per day. This

keeps all the programmers on the same page, and makes very rapid progress possible.

Perhaps surprisingly, integrating more frequently tends to eliminate integration

problems that persists with teams who integrate less often.

40-hour Week

Tired programmers make more mistakes. XP teams do not work excessive

overtime, keeping themselves fresh, healthy, and effective.

On-site Customer

An XP project is steered by a dedicated individual who is empowered to de-

termine requirements, set priorities, and answer questions as the programmers

have them. The effect of being there is that communication improves, with less

hard-copy documentation - often one of the most expensive parts of a software

project.

Coding Standard

For a team to work effectively in pairs, and to share ownership of all the code,

all the programmers need to write the code in the same way, with rules that

make sure the code communicates clearly.

Page 8: Software lifecycle model report

Synchronize and Stabilize lifecycle Model:-

This lifecycle model defines an overall approach for managing & developing large-scale

software systems.

Sync-and-stabilize is a Systems Development Life Cycle methodology in which teams work

concurrently on individual application modules. They frequently synchronize their code with

that of other teams, and debug or “stabilize” their code regularly throughout the development

process. Synch-and-stabilize is Microsoft's attempt to scale-up a loosely structured small-

team ("hacker") style of product development.

Many small teams (3 - 8 developers per team) work in parallel.

Components will work together if changes are synchronized frequently.

o Complete recompilation is done at the end of the day so that developers can

check their work.

o A defect that breaks the build must be fixed immediately

Features are evolved incrementally with occasional innovations.

o Start with a "vision statement".

o Select features and establish priority of features with user input.

o Continued testing is done during development.

The product is stabilized at 3 or 4 milestone junctures in the project life.

o It is done thorough internal and external testing.

o Fixes almost all errors detected.

o "Zero-bug" release is aimed at the last milestone.

The special feature of this model is that the specification is complete only when the product is

ready. This model has been used extensively by many innovative companies. Some of the

example projects using this software development model are some small scale projects i.e.

first version of DOS, Lotus1-2-3, WordPerfect, Word or Excel. This process is also known as

"milestone", "daily build", "nightly build", and "zero-defect" process. The overall strategy of

this model is to quickly introduce products that are "good enough" to capture a mass market,

and then further improve the product, selling multiple product versions and upgrades.

Advantages of Synchronize-and-stabilize model:-

- The periodic system building approach makes way for testing the software for its

functionality and performance.

- Project monitoring will be easy as there will be intermediate milestones.

- The integration problems encountered in large projects using other models are eliminated

using this model.

Page 9: Software lifecycle model report

- Because of intermediate releases, the product can be made rich in feature by incorporating

the necessary feedback methodology.

Disadvantages of Synchronize-and-stabilize model:-

- A parallel independent testing team needs to work independently.

- The detailed specifications document will be made available only at time of release.

- Periodic system builds require a rigorous process to be defined for integration of various

modules.

Overview of Synch-and-Stabilize Development Approach

Planning Phase:-

Vision Statement:- Product and program management use extensive customer input

to identify and prioritize product features.

Specification Document:- Based on vision statement, program management and

development group define feature functionality, architectural issues, and component

interdependencies.

Schedule and Feature Team Formation:- Based on specification document,

program management coordinates schedule and arranges feature teams that each

contain approximately 1 program manager, 3-8 developers, and 3-8 testers (who work

in parallel 1:1 with developers).

Development Phase:- Feature Development in 3-4 sequential subprojects that results in a

milestone release. Program managers coordinate evolution of specification. Developers

design, code, and debug. Testers pair up with developers for continuous testing.

Subproject I First 1/3 of features: Most critical features

And shared components.

Subproject II Second 1/3 of features.

Subproject III Final 1/3 of features: Least critical

Features.

Stabilization Phase: - Comprehensive external and internal testing and final product

stabilization. Program managers coordinate OEMs (Original Equipment Manufacturer) and

ISVs and monitor Customer feedback. Developers perform final debugging and Code

stabilization. Testers recreate and isolate errors.

Internal Testing: - Thorough testing of complete product within the company.

External Testing:- Thorough testing of complete product outside the company by

"beta" sites such as OEMs, ISVs, and end-users.

Page 10: Software lifecycle model report

Release preparation: - Prepare final release of "golden master" diskettes and

documentation for manufacturing.

Synch-and-Stabilize Development Phase Breakdown:-

Time: Usually 2-4 months per Milestone

MILESTONE 1 (frst1/3 features):-

Development (Design, Coding, Prototyping)

Usability-Lab

Daily Builds

Private Release Testing

Feature Debugging:

Feature Integration

Code Stabilization (no severe bugs):

Buffer time: (20-50%)

MILESTONE2 (next 1/3)-

Development-

Usability Lab

Daily Builds

Private Release Testing

Feature Debugging

Feature Integration

Code Stabilization

Buffer time

MILESTONE3 (Last Set)-

Development,

Usability

Daily Builds

Private Release Testing

Feature Debugging

Feature Integration

Feature Complete

Code Complete

Code Stabilization

Buffer Time

Zero Bug Release

Release to Manufacturing

Page 11: Software lifecycle model report

FOUNTAIN MODEL

The model is created by Henderson-Sellers and Edwards. The Fountain model is a logical

improvement of the Waterfall model. The steps are still there, in the same sequence, however

at any step there can be a fallback to an earlier step. Moving through a number of steps and

falling back one or more steps, performed repeatedly, is far more flexible than the Waterfall

model.

The process will have following phases:

- Requirements Phase

- Object Oriented Analysis Phase

- Object Oriented Design Phase

- Implementation Phase

- Implementation and Integration Phase

- Maintenance

Advantages of Fountain model:-

- Do not have to freeze the requirements too soon.

- Interaction B/W Design and requirement is more.

- Able to start the coding earlier.

Page 12: Software lifecycle model report

(Stages in Fountain Model)

Analysis: Its basic strengths are that it supports iteration within phases, allows parallelism between

phases, and it is an incremental development. And its weakness is that it may be degraded

into code-a-bit test-a-bit which requires frequent iterations and refinements.

I think that the Fountain Model is a better model to use in the industry. Though it would be a

bit inappropriate for small projects. It has the flexibility to fall back on any phase if some

problems arise in between any of the previous phases. Also practically the requirements keep

on changing quite frequently. Even if there is an error in the understanding of the client

requirements, those can be easily rectified without much loss of project time for not very

huge systems. Also a combination of a fountain and a spiral model would be more effective

as the Spiral model could be used at the beginning in the requirements definition phase to

minimize the risks involved in the project. This will also lead to a reuse of the components

developed in the earlier phases.

SPIRAL MODEL

Page 13: Software lifecycle model report

The spiral Model includes the iterative nature of the prototyping model and the linear nature

of the waterfall model. This approach is ideal for developing software that is revealed in

various versions.

In each iteration of the spiral approach, software development process follows the phase-wise

linear approach. At the end of first iteration, the customer evaluates the software and provides

the feedback. Based on the feedback, software development process enters into the next

iteration and subsequently follows the linear approach to implement the feedback suggested

by the customer. The process of iteration continues throughout the life of the software.

Spiral Approach Phases

1. Customer Communication: Includes understanding the system requirements by

continuous communication between the customer and the system analyst.

2. Planning: Includes estimating Schedule, cost, and resource for the iteration.

3. Risk Analysis: includes identifying, estimating, and monitoring technical and

management risks, such as schedule slippage and cost overrun.

4. Engineering: Includes requirement gathering and design of the software system.

5. Construction and release: Includes coding, testing and deploying software at the customer

site and providing user-support documents.

6. Customer Evaluation: Includes evaluation of software by the customer and implementing

feedback in the next iteration of the software development.

Product:

Page 14: Software lifecycle model report

An example of the spiral model is the evolution of Microsoft Windows Operating system

from Windows 3.1 to windows 2003. We may refer to Microsoft windows 3.1 Operating

System as the first iteration in the spiral approach. The product was released and evaluated by

the customers, which include the market large. After getting the feedback from customers

about the windows 3.1, Microsoft planned to develop a new version of windows operating

system. Windows’95 was released with the enhancement and graphical flexibility. Similarly,

other versions of windows operating system were released.

Application:

The spiral model is mostly used in large projects. For smaller projects, the concept of agile

software development is becoming a viable alternative. The spiral model suit small (up to $3

million) software applications and not a complicated ($3 billion) distributed, interoperable,

system of systems.

Also it is reasonable to use the spiral model in projects where business goals are unstable but

the architecture must be realized well enough to provide high loading and stress ability. For

example, the Spiral Architecture Driven Development is the spiral based Software

Development Life Cycle (SDLC) which shows one possible way how to reduce the risk of

non-effective architecture with the help of a spiral model in conjunction with the best

practices from other models.

Advantages

1. Realism: the model accurately reflects the iterative nature of software development on

projects with unclear requirement.

2. Flexible: incoporates the advantages of the waterfall and rapid prototyping methods

3. Comprehensive model decreases risk

4. Good project visibility.

Disadvantages

1. Needs technical expertise in risk analysis to really work

2. Model is poorly understood by nontechnical management, hence not so widely used

3. Complicated model, needs competent professional management. High administrative

overhead.

Page 15: Software lifecycle model report

RAPID APPLICATION DEVELOPMENT

Rapid application development is a software development methodology that involves

methods like iterative development and software prototyping. According to Whitten

(2004), it is a merger of various structured techniques, especially data-driven Information

Engineering, with prototyping techniques to accelerate software systems development.[1]

In rapid application development, structured techniques and prototyping are especially used

to define users' requirements and to design the final system. The development process starts

with the development of preliminary data models and business process models using

structured techniques. In the next stage, requirements are verified using prototyping,

eventually to refine the data and process models. These stages are repeated iteratively; further

development results in "a combined business requirements and technical design statement to

be used for constructing new systems"

RAD approaches may entail compromises in functionality and performance in exchange for

enabling faster development and facilitating application maintenance.

Four phases of RAD

Page 16: Software lifecycle model report

1. Requirements Planning phase – combines elements of the system planning and

systems analysis phases of the System Development Life Cycle (SDLC). Users,

managers, and IT staff members discuss and agree on business needs, project scope,

constraints, and system requirements. It ends when the team agrees on the key issues

and obtains management authorization to continue.

2. User design phase – during this phase, users interact with systems analysts and

develop models and prototypes that represent all system processes, inputs, and

outputs. The RAD groups or subgroups typically use a combination of Joint

Application Development (JAD) techniques and CASE tools to translate user needs

into working models. User Design is a continuous interactive process that allows

users to understand, modify, and eventually approve a working model of the system

that meets their needs.

3. Construction phase – focuses on program and application development task similar

to the SDLC. In RAD, however, users continue to participate and can still suggest

changes or improvements as actual screens or reports are developed. Its tasks are

programming and application development, coding, unit-integration and system

testing.

4. Cutover phase – resembles the final tasks in the SDLC implementation phase,

including data conversion, testing, changeover to the new system, and user training.

Compared with traditional methods, the entire process is compressed. As a result, the

new system is built, delivered, and placed in operation much sooner. Its tasks are data

conversion, full-scale testing, system changeover, user training

AGILE MODEL

Agile is a significant departure from the heavyweight document-driven software development

methodologies such as Waterfall model. Agile methodologies embrace iterations. Small

teams work together with stakeholders to define quick prototypes, proof of concepts, or other

visual means to describe the problem to be solved.

The team defines the requirements for the iteration, develops the code, and defines and runs

integrated test scripts, and the users verify the results. One specialty of this model is that

verification occurs much earlier in the development process than it would with waterfall,

allowing stakeholders to fine-tune requirements while they’re still relatively easy to change.

Page 17: Software lifecycle model report

image taken from: cs.utexas.edu/users/downing/papers/Agile2007.pdf

Types of agile software development methodologies :

XP (Xtreme Programming)

Scrum Methodology

EXTREME PROGRAMMING

Extreme programming is very far from difficult ,large or complex projects .Extreme

Programming, also called XP, is a lightweight method of software development based on

principles of communication ,simplicity, courage and feedback . XP is designed for small

teams who need to build the software quickly in an environment of rapidly-changing

re-quirements . It works by bringing the whole team together in the presence of simple

practices, with required feedback to enable the team to see where they stand and to modify

the practices according to their unique situation.

Extreme Programming can be summed up into twelve practises:

The Planning Process

The XP planning process allows the XP customer to set and define the business value

of desired features, and uses cost estimates provided by the coders to choose what needs to be

done and what not. The effect of XP’s planning process is that it is easy to propell the project

to success.

Page 18: Software lifecycle model report

Small Releases

XP teams put a simple system into production early, and update it frequently

through a very short cycle.This is repeated for many iterations.

Metaphor

XP teams use a common “system of names” and a common system description

that guides development and communication.

Simple Design

A program built with XP should be the simplest program and it should meet the current

requirements.There is not much building for the future”. Instead, the focus is

on providing business value. Of course it is necessary to ensure that you have a

good design, and in XP this is brought about through “refactoring”, discussed

below.

Testing

XP teams focus on validation of the software at all times. Programmers de-

velop software by writing tests first, then software that fulfills the requirements

reflected in the tests. Customers provide acceptance tests that enable them to

be certain that the features they need are provided.

Refactoring

XP teams improve the design of the system throughout the entire development.

This is done by keeping the software clean: without duplication, with high

communication, simple, yet complete.

Pair Programming

XP programmers write all production code in pairs, two programmers working

together at one machine. Pair programming has been shown by many exper-

iments to produce better software at similar or lower cost than programmers

working alone.

Collective Ownership

All the code belongs to all the programmers. This lets the team go at full speed,

because when something needs changing, it can be changed without delay.

Continuous Integration

XP teams integrate and build the software system many times per day. This

keeps all the programmers on the same page, and makes very rapid progress possible.

Perhaps surprisingly, integrating more frequently tends to eliminate integration

problems that persists with teams who integrate less often.

40-hour Week

Page 19: Software lifecycle model report

Tired programmers make more mistakes. XP teams do not work excessive

overtime, keeping themselves fresh, healthy, and effective.

On-site Customer

An XP project is steered by a dedicated individual who is empowered to de-

termine requirements, set priorities, and answer questions as the programmers

have them. The effect of being there is that communication improves, with less

hard-copy documentation - often one of the most expensive parts of a software

project.

Coding Standard

For a team to work effectively in pairs, and to share ownership of all the code,

all the programmers need to write the code in the same way, with rules that

make sure the code communicates clearly.

SCRUM METHODOLOGY

‘Scrum’ (related to “scrimmage”) is the term for a huddled mass of players engaged with

each other to get a job done in rugby. In software development, the job is to put out a release.

Scrum for software development came out of the rapid prototyping community because users

wanted a methodology that would support an environment in which the requirements were

not only incomplete at the start, but also could change rapidly during development.

At the center of each Scrum project, there is a backlog of work to be done. This backlog is

populated during theplanning phase of a release and defines the scope of the release. After the

team completes the project scope and high-level designs, it divides the development process

into a series of short iterations called sprints.

These sprints aim to implement a fixed number of backlog items. Before each sprint, the team

members identify the backlog items for the sprint. The team reviews the sprint to articulate

lessons learned and check progress at the end of sprint.

The Scrum development process concentrates on managing sprints. Before each sprint

begins, the team plans the sprint, identifying the backlog items and assigning teams to these

items. Teams develop, wrap, review, and adjust each of the backlog items. Below is picture

describing the Scrum method:

Page 20: Software lifecycle model report

PROJECT ENVIRONMENT IMPACT ON LIFE

CYCLE MODEL:-

Design and adaptation of the life cycle model for each project category or subcategory must

reflect the important characteristics of the project environment. So life cycle models are

categorized on the basis of Project types as following:

Project Categories Life Cycle Models

1. Aerospace/Defense Projects

1.1 Defense systems

1.2 Space

1.3 Military operations

Defense Acquisition Model.

Process Based Mission Assurance (PMBA)

Program Life Cycle model.

2. Business & Organization Change

Projects

2.1 Acquisition/Merger

2.2 Management process improvement

2.3 New business venture

2.4 Organization re-structuring

2.5 Legal proceeding

Generic Waterfall, Parallel-Work,

Evolutionary Models.

Standard Waterfall, Cyclical, Spiral Models.

3. Communication Systems Projects

3.1 Network communications systems

-do-

Page 21: Software lifecycle model report

3.2 Switching communications

systems

4. Event Projects

4.1 International events

4.2 National events

-do-

5. Facilities Projects

5.1 Facility decommissioning

5.2 Facility demolition

5.3 Facility maintenance and

modification

5.4 Facility

design/procurement/construction

-do-

6. Information Systems (Software)

Projects

Predictive (Waterfall, Prototyping, RAD,

Incremental Build, Spiral) and Adaptive

(ASD, XP, SCRUM) Models.

Code and Fix, Incremental, Iterative Model.

Formula-IT Development Model.

Refined Process Spiral Model.

7. International Development Projects

7.1 Agriculture/rural development

7.2 Education

7.3 Health

7.4 Nutrition

7.5 Population

7.6 Small-scale enterprise

Waterfall, Spiral Models.

8. Media & Entertainment Projects

8.1 Motion picture

8.2 TV segment

8.2 Live play or music event

-do-

9. Product and Service Development

Projects

9.1 Information technology hardware

9.2 Industrial product/process

9.3 Consumer product/process

9.4 Pharmaceutical product/process

9.5 Service (financial, other)

Stage/Gate Product Development Model.

Phase-Gate Process Model.

Pharmaceutical Model.

10. Research and Development Projects

10.1 Environmental

10.2 Industrial

10.3 Economic development

10.4 Medical

10.5 Scientific

Technical Acquisition: Basic Model, Phased

Model, Multi-Solution Model.


Recommended