90 (IJCNS) International Journal of Computer and Network Security,

Vol. 2, No. 5, May 2010

Factors Identification of Software Process Model –

Using a Questionnaire
Abdur Rahshid Khan1, Zia Ur Rehman2
1
Institute of Computing & Information Technology,
Gomal Univeristy Dera Ismail Khan, Pakistan
Email: drarashid.khan09@gmail.com
2
Institute of Information Technology,
Kohat University of Science and Technology (KUST),
Kohat, Pakistan
Email: ziagulzia@gmail.com

Building and running corporate-wide knowledge

Abstract: this work is an attempt to identify factors that are
critical to software process model for a software project. Diverse
types of software engineers can get benefit to select a software
process model during development of software project. A
questionnaire was developed with the help of domain experts,
cited literature and rules of thumbs. This was sent to 100
domain experts with highest qualification and a vast experience
of the fields of various institutions in Pakistan. Experts’
opinions from 34 domain experts were received with remarkable
comments and suggestions. This questionnaire will be used as a
Knowledge Acquisition tool for ESPMS (Expert System for
Software Process Model Selection); which will integrate the
knowledge of experts of various domains, like Software
Engineering, Artificial Intelligence and Project Management.
This questionnaire will lead to become a standard document of
knowledge acquisition for selection of an appropriate software
process model for a particular project. Further work is required
to verify this tool through experts of various organizations
(public and private) software houses within country and abroad.
Keywords: Software Engineering, Project Management,
Artificial Intelligence, Expert System, Knowledge Acquisition
Tool, Questionnaire
1. Study Background
Explicit models of software evaluation date back to the
earliest projects developing large software systems in the
1950’s and 1960’s [1]-[2]. The main purpose of early life
cycle models was to provide a conceptual scheme for
managing the development of software system. Since the
1960’s descriptions of the classic software life cycle have
appeared e.g., [1, 2, 3, 4 & 5].
If software is not a product, then software development is
not a product. It cannot be. If the true product is not the
software but the knowledge contained in the software, then
software development can only be a knowledge acquisition
activity. Translating that Knowledge into a specific
language form known as “code” [7]. Knowledge is crucial
resource of each organization and therefore it will be
carefully managed. Knowledge is intensive in business
areas. Knowledge is a mandatory source of business success
[6].
management systems in the domain of Software
Engineering is an idea that was initiated about 20 years ago
[8]. There are two types of knowledge, tacit knowledge and
explicit knowledge. Tacit knowledge is personal knowledge
embedded in personal experience and is shared and
exchanged through direct, face-to-face contact. Explicit
knowledge is formal or semi-formal knowledge that can be
packaged as information [6].
In article [6], author defined “Knowledge Management”
(KM) as human resource management activities, such as
hiring new staff or to train staff in order to increase the
company’s capacities. The goal of KM is to improve
organizational skills of all levels of the organization
(individual, group, division, organization) by better usage of
the resource knowledge. It is a management activity, and as
such is goal oriented, planned and monitored.
The three laws for process are: (1) Process only allows us
to do things we already know how to do. (2) We can only
define software processes at two levels: too vague or too
confining. (3) The very last type of knowledge to be
considered as a candidate for implementation into an
executable software system is the knowledge of how to
implement knowledge into an executable software system.
Author also focuses attention, that there are several
problems in defining process in industry [7].
Comperative Study of Software Process Models
Software process is a framework for the tasks that are
required to build high quality software [9].
A descriptive model describes the history of how a
particular software system was developed [4 & 13].
Prescriptive models are used as guidelines or frameworks
to organize and structure how software development
activities should be performed, and in what order.
Prescriptive models are also used to package the
development tasks and techniques for using a given set of
software engineering tools or environment during a
development project. Descriptive life cycle models,
characterize how particular software systems are actually
developed in specific settings [3 & 4].
 (IJCNS) International Journal of Computer and Network Security, 91
In order to ensure that cost-effective, quality systems are
developed which address an organization’s business needs,
developers employ some kind of system development
Process Model to direct the project’s lifecycle [10]. To solve
actual problems in an industry setting, a software engineer
or a team of engineers must incorporate a development
strategy that encompasses the process, methods, and tools
layers and the generic phases [9].
Software process models often represent a networked
sequence of activities, objects, transformations, and events
that embody strategies for accomplishing software evolution.
Software process networks can be viewed as representing
multiple interconnected task chains. Task chains can be
employed to characterize either prescriptive or descriptive
action sequences. Prescriptive task chains are idealized
plans of what actions should be accomplished, and in what
order [11].
Some of the important models have been described in the
following paragraphs.
The Linear Sequential Model, The linear sequential
model, sometimes called the Classic or Waterfall model,
proposed by Winsten Royce [11]. The linear sequential
model suggests a systematic, sequential approach to
software development that begins at the system level and
progresses through analysis, design, coding, testing, and
support [9].
Waterfall Model has some criticisms as:
• Real projects rarely follow the sequential flow that the
model proposes.
• At the beginning of most projects there is often a great
deal of uncertainty about requirements and goals, and it is
therefore difficult for customers to identify these criteria on
a detailed level. The model does not accommodate this
natural uncertainty very well.
• Blocking state: means in this model some project team
members must wait for other members of the team to
complete dependant tasks.
• Developing a system using the Waterfall Model can be
a long, painstaking process that does not yield a working
version of the system until late in the process [10].
The Prototyping Model: A customer defines a set of
general objectives for software but does not identify detailed
input, processing, or output requirements. In these, and
many other situations, a prototyping paradigm may offer the
best approach [9 &11].
There are a few different approaches that may be followed
when using the Prototyping Model [10]:
• Creation of the major user interfaces without any
substantive coding in the background in order to give the
users a “feel” for what the system will look like,
• Development of an abbreviated version of the system
that performs a limited subset of functions; development of a
paper system.
• Use of an existing system or system components to
demonstrate some functions that will be included in the
developed system.
Vol. 2, No. 5, May 2010
Criticisms of the Prototyping Model generally fall into the
following categories [10]:
• Prototyping can lead to false expectations.
• Prototyping can lead to poorly designed systems.
The RAD Model: Rapid Application Development
(RAD) is an incremental software development process
model that emphasizes an extremely short development life
cycle. It is a component-based construction, but high speed
linear sequential. If requirements are well understood and
project scopes constrained, the RAD process enables a
development team to create “a fully functional system” with
in very short time periods (e.g., 60 to 90 days) [9 & 11].
The RAD approach has drawbacks [9]:
• Large and scalable projects require sufficient human
resources.
• RAD requires developers and customers who are
committed to the rapid-fire activities necessary to get a
system complete in specified time. If commitment is lacking
from either constituency, RAD project will fail.
• If a system cannot be properly modularized, building
the components necessary for RAD will be problematic.
• If high performance is issue and performance is to be
achieved through tuning the interfaces to system
components, the RAD approach may not work.
• RAD is not appropriate when technical risks are
high. This occurs when a new application makes heavy use
of new technology or when the new software requires a high
degree of interoperability whit existing computer programs.
Evolutionary Software Process Model: Evolutionary
models are iterative, which is one of the modern software
development processes. Evolutionary models enable
software engineers to develop increasingly more complete
versions of the software [9 & 11].
Incremental Models: It combines elements of the linear
sequential model applied respectively with the iterative
philosophy of prototyping. First increment is often a core
product. It is iterative in nature [5 & 9].
The Spiral Model: The spiral model, proposed by [3], is
an evolutionary software process model that couples the
iterative nature of prototyping with controlled and
systematic aspects of the linear sequential model. A spiral
model is divided into a number of framework activities, also
called tasks or regions [9 & 11].
The Win-Win Spiral Model: The Customer wins by
getting the system or product that satisfy the majority of the
customer’s needs and the developer wins by working to
realistic and achievable budgets and deadlines. Boehm’s
WINWIN spiral model [12] defines a set of negotiation
activities at the beginning of each pass around the spiral.
Criticism of a spiral model: The risk assessment
component of the Spiral Model provides both developers
and customers with a measuring tool that earlier Process
Models do not have. The measurement of risk is a feature
that occurs every day in real-life situations but
(unfortunately) not as often in the system development
industry. The practical nature of this tool helps to make the
92
Spiral Model a more realistic Process Model than some of
its predecessors.
The Concurrent Development Model: The concurrent
development model is also called concurrent engineering,
[12]. The concurrent process model defines a series of
events that will trigger transitions from state to state for
each of the software engineering activities. A system and
component activities occur simultaneously and can be
modeled using the state-oriented approach described
previously. Each activity on the network exists
simultaneously with other activities [5, 9 & 11].
Component-Based Development: Object-Oriented
technologies provide the technical framework for a
component-based process model for Software Engineering
[5, 9 & 11]. A general criticism of the Component-Based
Model is that it is limited for use in object-oriented
development environments. Although this environment is
rapidly growing in popularity, it is currently used in only a
minority of system development applications [10].
1.1 Creating and Combining Models:
In many cases, parts and procedures from various Process
Models are integrated to support system development. This
occurs because most models were designed to provide a
framework for achieving success only under a certain set of
circumstances. It is sometimes necessary to alter the existing
model to accommodate the change in circumstances, or
adopt or combine different models to accommodate the new
circumstances. The selection of an appropriate Process
Model hinges primarily on two factors: organizational
environment and the nature of the application. Frank Land,
from the London School of Economics, suggests that
suitable approaches to system analysis, design, development,
and implementation be based on the relationship between
the information system and its organizational environment.
Four categories of relationships are identified: The
Unchanging Environment, the Turbulent Environment, the
Uncertain Environment, and the Adaptive Environment
[10].
1.2 Expert Systems Application
For decision making and for problem solving Expert
System tools are used, which is Artificial Intelligence tool,
they have ability to imitate the reasoning of human expert
with in a specialized area [14]. Now in various areas such as
computer science, agriculture, engineering, geology, space
technology, medicine, etc expert systems are being used and
developed (Durken 1990). The knowledgebase component of
expert system is consists of human experts’ knowledge. The
most difficult task is to acquire knowledge from experts and
identification of problem in the development of expert
systems [7, 8]. Interview, observation analysis, case study
analysis, questionnaire, protocol analysis are the some
knowledge acquisition techniques to acquiring knowledge
and expertise in domain experts [14, 15, 16 & 17].
(IJCNS) International Journal of Computer and Network Security,
Vol. 2, No. 5, May 2010
1.3 Knowledge Acquistion
Capturing knowledge source from expertise is known as
knowledge acquisition technique. There are different
sources from which knowledge can be acquired such as
human experts, books, journals, reports, databases and other
computer system [14]. The process through which
knowledge engineers extract knowledge called Knowledge
Acquisition [18]. Knowledge acquisition process is the first
phase to develop an expert system [18]. There are some
difficulties in during knowledge acquisition process i.e.
sometime problem is not very clear to knowledge engineers,
knowledge engineers have lack of knowledge in particular
domain, sometime experts are not available in particular
domain [16 & 18].
There are several reasons for employing an expert system
such as [14]:-
§ Replacement of human expert
§ Assistant to human expert
§ Transfer of expertise to novice
From literature study it is revealed that there are a
number of knowledge acquisition techniques exist, such as
questionnaire, protocol analysis, Interview (structured and
unstructured interview), case study analysis, observation
analysis, simulation and prototyping [14 & 15).
Depending upon the nature of the problem, need,
situation and domain experts, different acquisition
techniques can be used accordingly. If the domain experts
can easily be accessed, an interview is the best technique. If
the expert are far-away from access of knowledge engineers
or experts are much busy, then questionnaire is the most
suitable tool. Similarly, if the target problem is complex,
multiple techniques can be adopted.
2. Problem Domain
Knowledge acquisition process was started from
identification of critical factors that affect directly or
indirectly the process models, being critical in selection of
appropriate software process model to software engineers.
This tool will be used in ESPMS (Expert System for
Software Process Model Selection), which is available free
of cost.
Literature study reveals that research has been conducted
on different phases of software process models, such as
requirement analysis and specification, planning of software
project, System Design and Architectural Design etc but
there is no proper guidance for novice software designer and
engineer, how to select a process model for a particular
situation.
Ref [7] described the three laws of software process and
also highlighted that there are several problems in defining
a process in industry. Author also highlights rule of process
bifurcation (Software process rules that are stated in terms
of two levels: a general statement of the rule, and a specific
detailed example), and the dual hypothesis of knowledge
discovery (we can only “discover” knowledge in an
environment that contains that knowledge). Ref [6] stated
overall objective of Learning Software Organization (LSO)
 (IJCNS) International Journal of Computer and Network Security, 93
Vol. 2, No. 5, May 2010

is to improve software processes and products according to
the strategic goals of the organization. Knowledge
Management (KM) was defined, because KM is prerequisite
of learning organization. Ref [19] stated that there is still
lacking integration of software process modeling and
software process measurement by software engineers.
Language construct is used to better understand the process
modeling technique. The Attribute Grammar (AG) approach
to realize modeling of software processes modeling in
language construct is based on its specification and
automatic construction of language-based editors. Ref [20]
Build Knowledge Analysis System (KANAL), which relates
pieces of information in process models among themselves
and to the existing Knowledge Base (KB), analyzing how
different pieces of input are put together to achieve some
effect. It builds interdependency models from this analysis
and uses them to find errors and propose fixes. Ref [21]
Recent research in software engineering has moved away
from this linear approach of the life cycle in order to take
account of dependencies between decisions taken in
different parts of the development and to allow methods to
be selected during developments which are appropriate to
address problems that arise. The most advanced approach is
the spiral model proposed by Boehm [3]. The major research
project on KBS methodology is the KADS (Knowledge
universities of Pakistan. 100 domain experts along with
detailed about them were found in 124 universities of
Pakistan. See Table I for detail.
3.2 Design and Distribution of Questionnaire
Extracting experts’ opinion to develop standard criteria
for factors that can affect software process model’s
performance is the main purpose of this questionnaire.
Questionnaire was the tool through which we could solicit
experts’ opinion. A total of 99 questions (parameters) were
identified, which were grouped into 11 main factors. Five
fuzzy variables scales were defined, like, 5=Strongly Agree
(Critical to process’s performance), 4 = Agree (Important to
process’s performance), 3= Neutral (Helpful to process’s
performance), 2= Disagree (Minimally affects process’s
performance), 1= Strongly Disagree (Do not affect process’s
performance).
We designed the questionnaire in such a way that the
respondent have to rank the importance of factor regarding
to its objective. Among 100 domain experts we received 34
experts’ opinions with valuable and remarkable suggestions.
Table 1: Experts Detail with their Responses
Experts’ Subject
Charac.
Gender Designation Degree
Specialty
Demographic

Acquisition and Design System). KADS proposes that Software

Male: 30 Professor: 4 PhD: 4 Engineeri Federal: 10
knowledge modelling should pass through five stages: ng: 20
(Data, Conceptual Model, Design Model, Detailed Design Associate M.Phil/M
Artificial
Categorical Female:4 Intelligenc Sindh:0
Model, and Implementation). The Conceptual Model is Responses
Professor: 8 S:12
e: 8
further divided into a four layer knowledge model where Assistant MCS/
Software
Project
- Punjab:4
each successive layer interprets the description of the lower Professor: 9 MSc: 12 Managem
ent: 6
layer: static domain knowledge, knowledge sources, task, BCS
- - Lecturers: 7 - NWFP:10
and strategic knowledge. The major difficulty with advice (Hons): 6
Baluchistan:
on maintenance is that there is very little data or published - - Teachers: 6 - -
10
Azad Jammu
experience on maintaining KBS. Two main properties - - - - -
& Kashmir: 0
directly influence the maintainability of a KBS. (1) The - - - - -
Total: 34 34 34 34 34 34
homogeneity of the maintained representation: (2) the
predictability of the representation.

3. Approach 3.3 Analysis and Findings

In this research we are introducing the tool (i.e. a SPSS was used to analyze the collected facts. Table 2
questionnaire) for knowledge acquisition process to solve a shows the summary of questionnaire distribution.
selected problem. During development of this Knowledge
Acquisition tool, following steps were adopted: Table 2: Questionnaire Distribution
A). Selection of Domain Experts Medium Questionnaire Responses %age
Distributed
(B), Design and Distribution of Questionnaire and Through Email 60 20 33.33
(C) Analysis and Findings. Through Post 28 9 32.14
3.1 Selection of Domain Experts Through By hand 12 4 33.33
Total 100 34 34
Knowledge Base (collection of expert knowledge) is
critical and important component of the expert system [22]. The questionnaire was resulted in 11 main groups with 84
The questionnaire was properly evaluated by domain questions after repeatedly contact with the domain experts.
experts, which will lead to become a standard document for Statistical analysis showed that System Integration &
selection of appropriate software process model. Testing, User Community & Unit Development, Software
In Pakistan SE and AI are used mostly for research in Integration & Testing were the most important factors
Education, that’s why this questionnaire was distributed in among rest of the main factors. See Table 3 for detail.
various Higher Education Commission (HEC) recognized
94 (IJCNS) International Journal of Computer and Network Security,
Vol. 2, No. 5, May 2010

The ranking of factors were also helpful in determining standard tool for selection of an appropriate software process
the weights of the various factors, which influence the model but it is just an approach, guideline and helping tool
decision making process. for software engineer in selection of process model. This
questionnaire may become a standard Knowledge
Table 3: Response Summary for Affect on Proces’ Acquisition tool for Expert System development.
Performance
(Total Reponses N: 34, 5= Critical Affects, 1= Do not Affect)
Std. Domain Experts
Main Groups of Factors Mean
Deviation (Books, Journals, Databases, Reports, Internet etc)
System Integration and Testing 3.8941 1.1494
User Community 3.4510 1.1441 Reference Knowledge
Unit Development, Software Integration &
Testing 3.7426 1.0890
Implementation & Maintenance 3.7904 1.0881 Characteristics of Software Process Models
Project Type and Risk Management 3.7941 1.0184
Validation and Verification 3.8168 0.9981
Quality Assurance and Quality Control 3.8333 0.9774
Requirement Analysis and Specification 3.8407 0.9762 Factors Identification
System Design and Architectural Design 3.8848 0.9613
Project Team 3.8445 0.9565
Analyzed Facts
Documentation 4.1823 0.8577 (Knowledge Elicitation)

Table 4 depicts weights assigned to the main factors. In

weight criteria documentation, system integration and
testing and validation and verification were the most
important factors among rest of the main factors.
Table 4: Weight Assignment to main factors
S.No Main Groups of Factors
s
1 Documentation
2 System Integration and Testing
3 Validation and verification
System Design and Architectural
4 0.0956
Design
5 Quality Assurance and Quality Control
6 Project Team
7 Implementation & Maintenance
Requirements Analysis And
8 0.0914
Specification
9 Project Type and Risk Management
Unit Development, Software Integration
10
& Testing
11 User Community
Total weight:
After calculation of mean and standard deviation of main
factors, we calculated mean and standard deviation of each
and every sub-factor (questions).
4. Conclusions and Future Recommendation
Each and every factor was properly analyzed, means and
standard deviations were calculated of each factors with the
help of SPSS. Weights of the main factors were evaluated.
Overall score will be calculated at run time through
summation function, which will be used for ranking in the
selection of a process model. (See my research thesis for
detail).
It is further recommended that this questionnaire is not in
final shape which will be distributed in local (Pakistan) and
international software houses. This questionnaire is not final
Questionnaire
Figure 1: Knowledge Elicitation Process of a Software
Process Model Selection
Weight
References
0.1041
0.0971 [1] Hoiser, W.A., “Pitfalls and Safegaurds in Rea-Time
0.0969 Digital Systems with Emphasis on programming,” IRE
Trans. Engineering Management, EM-8, June 1961.
[2] Royce, W. W., “Managing the Development of Large
0.0952 Software Systems,” Proc. 9th. Intern. Conf.Software
0.0923 Engineering, ,IEEE Computer Society, 1987 ,328-338
0.0915 Originally published in Proc. WESCON, 1970.
[3] Boehm, B., “ A Spiral Model for Software
Development and Enhancement,” Computer, Vol. 21,
0.0849
no. 5, May 1988, pp. 61-72
0.0793 [4] Scacchi W., Process Models in Software
0.0718 Engineering, Institute for Software Research,
1.0000 University of California, Irvine February 2001.
[5] Sommerville I., Software Engineering 5th Edition,
2000
[6] Ruhe G. (2000), “ Learning Software Organizations”,
Fraunhofer Institute for Experimental Software
Engineering (IESE).
[7] Caesar & Cleopatra (2004), “Chapter 1,The Nature of
Software and the Laws of Software Process” www.ism-
journal.com/ITToday/AU1489_C01.pdf, CRC Press,
LLC.
[8] Basili V.R, Zelkowitz, M. V. McGarry, F. Page, S.
Waligora, R. Pajerski. SEL’s Software Process
Improvement Program, IEEE Software, vol. 12,
November, pp 83-87, 1995.
[9] Pressman R. S, Software Engineering a Practitioner ’s
Approach, Fifth Edition, 2001.
[10] SUNY 1988 , “ A Sur vey of System
Development P r ocess Models ” , CTG.MF A –
 (IJCNS) International Journal of Computer and Network Security, 95
Vol. 2, No. 5, May 2010

00, Center for Technology in Government, [27] Liu & Perry (2004), “On the Meaning of Software
University at Albany. Architecture, Interview Questionnaire, (July, 2004),
[11] Reddy A. R. M, Govindarajulu P., Naidu M., A Version 1.2
Process Model for Software Architecture, IJCSNS,
VOL.7 No.4, April 2007. Authors Profile
[12] Davis, A. and Sitaram P., “ A Concurrent Process
Model for Software Development,” Software Abdur Rashid Khan is presently working as an Associate
Engineering Notes, ACM Press, vol. 19, n0. 2, April Professor at ICIT, Gomal University D.I.Khan, Pakistan. He has
received his PhD degree from Kyrgyz Republic in 2004. His
1994, pp. 38-51 research interest includes AI, Software Engineering, MIS and DSS.
[13] Curtis, B., H. Krasner, and N. Iscoe, A Field Study of
the Software Design Process for Large Systems, Zia Ur Rehman is currently pursuing his MS degree in
Communications ACM, 31, 11, 1268-1287, November, Computer Science from the Institute of Information Technology,
1988. Kohat University of Science & Technology (KUST), Kohat,
Pakistan. His area of interest includes Software Engineering,
[14] Awad, E.M. “Building Experts Systems: Principals, Artificial Intelligence/Expert System, Databases and Data Mining.
Procedures, and Applications,” New York: West
Publishing Company. 1996.
[15] Durkin, J. “Application of Expert Systems in the
Sciences,” OHIO J. SCI. Vol. 90 (5), pp. 171-179,
1990.
[16] Medsker, L. and Liebowits, J. “Design and
Development of Experts Systems and Neural
Networks,” New York: Macmillan Publishing
Company, 1987.
[17] Sagheb-Tehrani, M.“The design process of expert
systems development: some concerns, Expert system,”
Vol. 23 (2), pp. 116-125, 2006.
[18] Wagner, W.P., Najdawi, M.K., Chung, Q.B “Selection
of Knowledge Acquisition techniques based upon the
problem domain characteristics of the production and
operations management expert systems,” Expert
system, vol. 18 (2), pp. 76-87, 2001.
[19] Atan, R. Abd, A. A. Ghani, M. H.S. & Mahmod, R. “
Software Process Modelling using Attribute Grammar”
University Putra Malaysia, Serdang, Selangor Darul
Ehsan, Malaysia, IJCSNS International Journal of
Computer Science and Network Security, VOL.7 No.8,
August 2007.
[20] Kim, J. & Gil, Y. “Knowledge Analysis on Process
Models”, Information Sciences Institute University of
Southern California, International Joint Conference on
Artificial Intelligence (IJCAI-2001), Seattle,
Washington, USA, August 2001.
[21] Wilson, “Knowledge Acquisition: The current
position”, Science and Engineering Research Council
Rutherford Appleton Laboratory.
[22] Lightfoot,J.M.” Expert knowledge acquisition and the
unwilling experts: a knowledge engineering
perspective,” Expert system, vol. 16(3), pp.141-147,
1999.
[23] Futrell R. T., Shafer L. I, Shafer D. F, “Quality
Software Project Management”, Low Price Edition,
2004.
[24] Anderson S., & Felici M., “Requirement Engineering
Questionnaire”, Version 1.0, Laboratory for
Foundation of Computer Science, Edinburgh EH9 3JZ,
Scotland, UK (2001).
[25] Skonicki M., “QA/QC Questionnaire for Software
Suppliers”, January 2006.
[26] Energy U. S. D., “Project Planning Questionnaire”,
www.cio.energy.gov/Plnquest.pdf (last access, 04
August 2009)
96 (IJCNS) International Journal of Computer and Network Security,
Vol. 2, No. 5, May 2010

Appendix: (Questionnaire)
A SURVEY ON FACTORS AFFECTING TO SELECT A SOFTWARE DEVELOPMENT PROCESS MODEL
Respondent’s Name: _______________ Qualification: _________ Designation: ______________ Address/University: __________________________

INSTRUCTIONS
Different software process model exist, to select one for a particular software depends upon the nature of project, problem structure, risk involve, budget
estimation, goals & objectives of the project etc. As an EXPERT in this area, you are requested to examine each item in terms of suitability and then to explain
the degree of your agreement to each item whether, in your opinion, it would measure the factors affecting the selection of software development process model
and to what extent. You may recommend new & delete unnecessary items from the existing scale. Your in-time response will highly be appreciated. Please, use
the scale below to mark (P) your responses in the area provided.
5= Strongly Agree 4= Agree 3=Neutral 2= Disagree 1=Strongly Disagree
Critical to Process’s Important to Process’s Helpful to Process’s Minimally affects Process’s performance Do not affect Process’s performance
Performance Performance performance
ATTRIBUTES LEVELS
5 4 3 2 1
1 Requirements Analysis And Specification

1.1 Are the requirements precisely defined, well defined and well known?
1.2 Are requirements sufficient to help you understand the problem structure?
1.3 Are the requirements defined early in the cycle [23]?
1.4 Are the requirements will change often in the cycle [23]?
1.5 Is there need to demonstrate capability proof of concept [23]?
1.6 Does the requirement indicate a complex system/simple system [23]?
1.7 Is there appropriate procedure prepared for cost/benefit analysis [24]?
1.8 Does the requirements phase meet the requirements methodology [24]?
1.9 Are you sensible to organizational and political factors which influence requirements sources while eliciting requirements [24]?
1.10 Have you reuse requirements from other systems which have been developed in the same application area [24]?
1.11 How do you handle continuous requirements change [24]?
1.12 Does any risk analysis are performed on requirements [24]?
1.13 Is the requirements document easy to change [24]?
1.14 Do you define Cost-effectiveness criteria [24]?
1.15 Do you identify accuracy and completeness risks on the requirements analysis [24]?
1.16 Are rules established on handling inaccurate and incomplete data [24]?
1.17 Do you cross-check operational and functional requirements against safety (or security, availability, etc.) requirements [24]?
1.18 Are specifications kept up-to-date and controlled [25]?
1.19 Are your software-product versions reviewed for conformity to customer’s specifications [25]?
1.20 Are the versions reviewed for compliance to quality requirements before submission for customer approval [25]?
2 Project Team
2.1 Does the majority of team members new to the problem domain [23]?
2.2 Does the majority of team members new to the technology domain [23]?
2.3 Is there need to train to project team [23]?
2.4 Is the team more comfortable with structure than flexibility [23]?
2.5 Will the project manager closely track the team’s progress [23]?
2.6 Is ease of resource allocation important [23]?
2.7 Does the team accept peer reviews and inspections, management/customer reviews, and mile-stones [23]?
3 User Community
3.1 Will the availability of the user representatives be restricted or limited during the life cycle [23]?
3.2 Are the user experts in the problem domain [23]?
3.3 Do the users want to be involved in all phases of the life cycle [23]?
4 Project Type and Risk
4.1 Dose the customer want to track project progress [23]?
4.2 Does the project identify a new product direction for the organization [23]?
4.3 Is the project a system integration project [23]?
4.4 Is the project an enhancement to an existing system [23]?
4.5 Is the funding for the project expected to be stable throughout the life cycle [23]?
4.6 Is the product expected to have a long life in the organization [23]?
4.7 Is high reliability a must [23]?
4.8 Is the system expected to be modified perhaps in ways not anticipated, post-deployment [23]?
4.9 Is the schedule constrained [23]?
4.10 Are the modules interfaces clean [23]?
 (IJCNS) International Journal of Computer and Network Security, 97
Vol. 2, No. 5, May 2010

4.11 Are reusable components available [23]?

4.12 Are resources (time, money, tools, and people) scarce [23]?
4.13 What measurements will be used to track this project (Cost, Schedule Effort, LOC, Defects, Function Points Other ______) [26]?
5 System Design and Architectural Design
5.1 Does a design phase schedule exists which identifies tasks, people, budgets and costs?
5.2 Do you develop complementary system models [24]?
5.3 Do you model the system’s environment [24]?
5.4 Do you model the system architecture [24]?
5.5 Do you use structured methods for system modeling [24]?
5.6 Do you define operational processes to reveal process requirements and requirements constraints [24]?
5.7 Do you use a data dictionary [24]?
5.8 Do you document the links between stakeholder requirements and system [24]?
5.9 Do you specify systems using formal specifications [24]?
5.10 Can the data required by the application be collected with the desired degree of reliability [24]?
5.11 Do you identify non functional requirements (e.g., usability, quality, cognitive workload, etc.) for a system [24]?
5.12 Are significant software changes expected during the life of the project [24]?
6 Unit Development, Software Integration & Testing
6.1 Will the application system be run in multiple locations [24]?
6.2 If an on-line application, will different types of terminal be used [24]?
6.3 Is the proposed solution dependent on specific hardware [24]?
6.4 Have the portability requirements been documented [24]?
7 Quality Assurance and Quality Control
7.1 Have you written Quality Assurance plan? Or written record for Quality Assurance program [25]?
7.2 Have you performed internal quality audits on software design processes and configuration management functions [25]?
7.3 Is there any implementation of a formal correction action process for customer complaints [25]?
8 System Integration and Testing
8.1 Are software depends on Operating Environment(s)? (MS Windows, OS/2, Unix/AIX, Windows N/T, Macintosh, Novell, CICS,
DOS, Sun, Web Browser (specify), other ______________) [26]?
8.2 Are constraints effects the targeted operating environment(s)? (Firewalls, Transmission speed, Server capacity, Security, Workstation
capacity, Remote access capability, Widely dispersed user community without appropriate inter-operability Other [26]?
8.3 Which programming languages you will be, or are considering used in project? (Cobol, Java, C++, Visual Basic, FoxPro, Paradox,
HTML, Delphi, Visual C++, Power Builder, Others ____________) [26]?
8.4 Are the software’s operations (System/Application) so essential that data must be immediately available at all times or recoverable?
(Data recovery, Backups, Fault Tolerance, System Performance, Mirroring/Imaging Disaster Recovery) [26]?
8.5 Which individual, team, and organizational information systems development and management practices will be implemented on this
project? Project Planning, Requirements Management, Configuration Management, Project Tracking and Oversight, Quality Assurance,
Sub-Contractor Management, Risk Assessment, Peer Reviews, Training Program Software Product Engineering, Inter-group
Coordination, Integrated Software Management, Organizational Process Definition, Organizational Process Focus Defect Tracking,
Other_________________________ [26]?
9 Validation and verification
9.1 Is there any implementation of formal process for functional requirement review [25]?
9.2 Is there any implementation of formal process for system design review [25]?
9.3 Is there any implementation of formal process for code testing [25]?
9.4 Is there any implementation of formal process for integration testing [25]?
10 Documentation
10.1 Are written test plans, instructions, product specifications, and system design documents available to support the tests [25]?
10.2 Are functional requirements properly documented [25]?
10.3 Have you created system programmers documentation [25]?
10.4 Have you documented functional specification [25]?
10.5 Have you documented the system design [25]?
11 Implementation & Maintenance
11.1 Do you implement a formal set of code testing procedures?
11.2 Do you implement a formal set of integration testing procedures?
11.3 Have you implemented a formal process for acceptance testing by the User / customer?
11.4 Are you usually concerned with reusability while designing [27]?
11.5 Do you involve external (from the project) reviewers in the validation process [24]?
11.6 Has the expected life of the project been defined?
11.7 Has the importance of keeping the system up to date functionally been defined [24]?
11.8 Which medium will be used for the project/system documentation? Web Site, Hardcopy, CD Rom, Online Help, Video Quick
Reference Card Diskette, Other [26]?

Comments:___________________________________________________________________________________________________________________________________

Date: ____________________ Signature: ______________