Road Map To Design Successful Software - Ictms (Integrated Clinical Trial Management System)

INTERNATIONAL JOURNAL OF EMERGING TECHNOLOGIES AND
APPLICATIONS IN ENGINEERING, TECHNOLOGY AND SCIENCES (IJ-ETA-ETS)

ISSN: 0974-3588 | December 2014 | special issue
ROAD MAP TO DESIGN SUCCESSFUL SOFTWARE ICTMS (INTEGRATED CLINICAL TRIAL

MANAGEMENT SYSTEM)
SANJAY P. VARMA 1 , DR. PANKAJ J. GANDHI 2
1
CEO, Life Research Centre, Surat, Gujarat, India, and Ph D (Management) Scholar,
Department of Management, Sai Nath University, Ranchi, Jharkhand, India.
2
Visiting Professor in Management at Veer Narmad South Gujarat University, Surat,
Gujarat, India and Consultant at P J Gandhi & Associates, Surat, Gujarat, India.
1
drspvarma@hotmail.com, 2pnpj71@gmail.com
ABSTRACT: In this electronic era we are going to Design a Road Map to delivering Clinical Trial
Management Skill by developing web based module - ICTMS. In last decade, various agile methods have been
introduced and used by software industry. According to the requirements, software industry people use different
models to develop different software. There are various models but none of them is capable to address the issues
of client satisfaction. Software development that lays special emphasis on highly structured lifecycle and
defining an output with each stage and also tries to fulfil the objective of the Software Engineering of
developing high quality product within schedule and budget. This model is designed in such a way that it allows
client and developer to interact freely with each other in order to understand and implement requirements in a
better way. Software Development Life Cycle (SDLC) methodologies are mechanisms to assure that software
meet established requirements. These methodologies impose various degrees of discipline to the software
development process with the goal of making the process more efficient and predictable. It has been observed
that many practitioners are using hybrid of agile methods and traditional methods. Every agile method has its
own development cycle that brings technological, managerial and environmental changes in organization. A
proper roadmap of agile software development in the form of agile software development life cycle can be
developed to address the aforesaid issues of agile software development process. Thus, there is strong need of
agile software development life cycle that clearly defines the phases included in any agile method and also
describes the artefacts of each phase. This generalization of agile software development life cycle provides the
road map to developers about usability, suitability, applicability of agile methods.
Keywords: CTMS, Software Development Life Cycle (SDLC), Agile Software Development; Extreme
Programming, Adaptive Software Development, Agile Method, Road Map, Client Satisfaction.
1.
Introduction:
The CTMS market is developing and fast moving to keep up with the rate of change within the software
industry. The CRO industry is demanding far greater standardization, out-of-the-box functionality and greater
flexibility in low budget pricing. These demands are a reaction to increasing complexity in the operating
environment and the clinical trials management. Pharmaceutical companies are outsourcing more clinical trial
execution to contract research organizations to increase their own sourcing flexibility and to focus on drug
discovery and higher value activities. With personalized medicine, complexity of trial and increasing regulatory
requirements, clinical trials are becoming more and more complicated. These issues are combined with Key
Performance Index, integration of various module and near-real-time report demands, mean contract research
organizations are increasing their adoption of CTMS solutions. Due to the competitive intensity of the CTMS
market developer face challenge to developing better solutions.
Software Engineering is a discipline whose aim is the production of quality software, software that is delivered
on time, within budget and that satisfies its requirements [1] [2]. Software Engineering is the area which is
constantly growing. Clients requirement and satisfaction is the important quality issue. Satisfying client is an
essential element for staying in this modern world of global competition. Software Development Model must
satisfied and even delight client with the value of software products and services.
2.
Software development process and Methodologies:
A software development process, also known as a software development life cycle (SDLC), is a structure
imposed on the development of a software product. It is often considered as a subset of system development life
cycle. There are several models for such processes, each describing approaches to a variety of activities that take
IC-IKR-EMS : 07-12-2014 : Held at KITRC Kalol-382721 Gujarat , India
Page 288

place during the process. Software Engineering (SE) is the application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software. A software development process is a
structure imposed on the development of a software product. Software Engineering processes are composed of
many activities, notably the following: [3-16]
Requirements Analysis,
Specification
Software architecture
Implementation
Testing
Documentation
Training and Support
Maintenance
Software development teams, taking into account its goals and the scale of a particular project, and have a
number of well-established software development models to choose from. Therefore, even though there are
number of models, each software Development Company adopts the best-suited model, which facilitates the
software development process and boosts the productivity of its team members. There are four types of Model
are:
Waterfall
Iterative
Prototype
Spiral.
Phases of SDLC
Problem solving in software consists of these activities:
Understanding the problem
Deciding a plan for a solution
Coding the planned solution
Testing the actual program

For large systems, each activity can be extremely complex and methodologies and procedures are needed to
perform it efficiently and correctly. Furthermore, each of the basic activities itself may be so large that it cannot
be handled in single step and must be broken into smaller steps. The basic activities or phases to be performed
for developing software system are
Determination of Systems Requirements
Design of system
Development (coding) of software
System Testing
3.
Agile Method:
3.1 Introduction
Agile Methods (AMs) have been adopted by many IT organizations and have generated many quality products
of software industry. These methods have gained higher edge on traditional software development by
accommodating frequently changing requirements in high tight schedules [17].
AMs have promised higher customer satisfaction, low defect rates, higher usability and a solution to higher
changing requirements [18]. AMs include mainly; Extreme Programming (XP), Scrum, Feature Driven
Development (FDD), Crystal methodology, Dynamic System Driven Development (DSDM), Adaptive Software
Development (ASD), Open Source (OS), Agile Modelling (AM), and Pragmatic Programming (PP) [19]. It has
been observed that all aforesaid methods are based on agile manifesto and have their own software development
life cycle for improving productivity and quality of software [20]. It has been noticed that applicability of these
methods is mainly in small software with low life critical systems. Many opponents have claimed that agile
software development is set of ad-hoc practices and does not have sound principles behind it. Further, it has
been stated by many software researchers that it is hard for average software developer/ manager to understand
and manage entire agile approach to development [21]. Attempts have been made to reconcile the AMs with
plan driven methods [22]. Still, there is lack of a generalized Agile Software Development Life Cycle (ASDLC)
for AMs that include complete agile principles and practices as whole. Therefore, in this paper, we have
proposed ASDLC and also discuss the documents or artefacts required to produce in particular phase.
Page 289

3.2 Background
Many software development methods/ models have been proposed since the evolution of software. Some
development models had shown remarkable success in stable and predictable environment. At the same time,
these models have proven to be one of the major causes of failure in disruptive software development. In
internet and mobile technology, frequent changes in requirements, technology and staff have been observed
[23]. Thus, software development process has become more cumbersome in such environment. Traditional
Software Development Methods (TSDMs) are proven to be unsuccessful and software success rate of TSDMs is
less than 40% in such environments [24]. A new way of software development i.e. agile software development
is outcome of the frustration of many practitioners using TSDMs. In last decade, a number of AMs have been
evolved based on Agile Manifesto established in 2001 [www.agilemanifesto.org]. It is clear that DSDM not
only stresses on development but also includes the feasibility and business study. Further, it has been noticed by
many researchers that AMs do not follow all the phases of software development life cycle [19]. Some
researchers have attempted to include missing phases of SDLC in existing AMs [25]. However, there is strong
need to define generalized agile software development life cycle to increase the understandability of agile
practices and principle to increase the use of these methods.
3.3 Agile Software Development Life Cycle (ASDLC)
Proposed generalized Agile Software Development Life Cycle (ASDLC) is designed on the basis of common
practices and principles used in all existing AMs. We have defined various phases in ASDP and activities
performed in each phase along with artefacts required in each phase. Complete ASDLC is shown in Fig. 1 and
discussed as follows:
A. Vision and Project Approval
ASDLC starts with the vision or inception phase that deals with the need of new system by analyzing problems
in existing system. Management, product manager, users and team members establish the scope and boundary
conditions of proposed system. At this level, objective is apparent but the features fulfilling the objectives may
be uncertain. Main objective of this phase is to identify critical uses of the system, level of uncertainty of the
system, overall estimation of size and duration of the system using algorithmic or non algorithmic approach.
Further, systematic analysis is performed to identify the feasibility of the system at operational and economical
level with clear specified requirements. It is concerned with technical possibility of the system with incurring
risk associated with it. At same level, feasibility of particular AM is assessed. It has been noticed that early
estimation is useful in project approval.
B. Exploration Phase
Exploration phase is an iterative and incremental phase to reduce the uncertainty and ambiguities in
requirements by continuous meeting of stakeholders in the form of workshops and brainstorming. Some of
the AMs have preferred customer as team member but proposed ASDLC recommends the maximum
communication between team and customer to resolve the requirement related issues by using any preferred
mode of communication between customer and team [25]. Requirements may be captured in form of stories and
documented in story cards that can be referred for future references. Typical format of story cards contains
information about author, story id, story description, further changes in story and details of related stories etc.
[26]. Artefacts produced are informal requirements description in the form of stories.
Generally, while experienced team members are working on requirements inexperienced team members have
been trained on agile process and technology used for training and enhances the ways to improve quality of
product being developed.
C. Iteration Planning
Iteration planning is most important phase of ASDLC and possesses many activities of software development
required to schedule the project. First activity in this respect is review of the working software released in last
iteration. Participants assess the progress and increment of the work product and discuss the future plan of the
project. Project manager, customer representative and team members sit together to decide the priority of
requirements. Moreover, iteration plan phase possesses iterative estimation activity to estimate size, cost and
duration of the project. It also re-estimates efforts depending on team velocity [29].
Page 290

This phase also ensures the resource requirements of the system. Artefacts produced in this phase are prioritized
stack requirements and set of requirements from the stack is selected for current iteration.
C. ADCT Phase
This phase is an iterative phase that deals with Analysis, Design, Coding, and Testing (ADCT). In this phase,
functionality of the system is produced and enhanced in new increments. It requires several iterations before
releasing the product. Decided schedule in iteration planning is decomposed in several small iterations of one to
four weeks. First iteration develops the architecture of whole system by enforcing the selection of stories that
form the system. Main activities of this phase are simple designing, maintaining coding standards and rigors
testing by Test Driven Development (TDD) and functional testing. Extra care is taken to design a code simply
by code and data re-factoring. Major artifacts in this phase are design documents and codes of system.
D. Release Phase.
This phase can be decomposed in two sub-phases
Namely, pre-release and production as shown in Fig 1. Pre-release: Phase recommends extra testing (i.e.
integration and acceptance testing) and checking of functional and non-functional requirements of the system to
be released. It has been observed that team handles two responsibilities after first release of the system. Firstly,
team is involved in enhancing the functionalities of product. Secondly, team has to take responsibility of system
in running state thereby providing customer helpdesk.
We have attempted to define the ASDLC after reviewing the all phases of software development of existing
AMs. We have also included the phases introduced by other researchers thereby increasing the trust and faith on
agile software development.
4.
Project Planning and Management:
Project Management aspect in software development. A software development lifecycle is a structure imposed
on the development of a software product. Synonyms include development lifecycle and software process.
There are several models for such processes, each describing approaches to a variety of tasks or activities that
take place during the process. [27]
Product Development
Identify a Problem that needs to be solved
Create a plan for your Solution to the Problem
Design the software necessary for the Solution
Implement the software that supports the Design
Release/Deploy the software Support the software
Project Management Required
High-level guidelines, interpreted and implemented differently across teams and projects
Phases can overlap and can have smaller cycles nested Engineering Disciplines
Program Management (PM) Development (Dev)
Testing (Test)
PUM Organizational Model
Single point of ownership across disciplines
Doesnt scale as well to large complex systems
Smaller teams create less career development opportunities Most often found in smaller teams
Functional Organizational Model
Dev/Test/PM work together as a triad to make product decisions, escalation to VP for issues No single point
of ownership on a specific feature Scales better to large organizations Creates significant critical mass within
a discipline Most often used in large complex projects.
PM Responsibility
Defining the Problem Space Understanding customer requirements, industry direction, competitors Create
Solution Framework together with engineering team UI guidelines, system architecture, design constraints,
domain modelling
Create Solution Specification Document high priority/impact design decisions, document exit criteria
Project Management Project tracking, status reporting, communication, risk assessment / mitigation
What makes a great PM?
Someone who loves technology and is passionate about how it can be used to have a real impact on customers
lives Must always be thinking about how to optimize Must be a great diplomat Must be always finding
ways to simplify.
Developer Responsibility Develop Solution
Framework/Specification together with PM
Document technical Design/Architecture
Delivering quality Code that matches both
Solution Framework and Specification and has been adequately Tested Support code/service after release
What makes a great Tester?
Page 291

Passionate about making sure our systems improve the lives of our customers Excellent problem
solving/troubleshooting skills Can stay much focused on the smallest details and ensure nothing is left to
chance Good at approaching a problem from multiple perspectives
What makes a great Tester?
Passionate about making sure our systems improve the lives of our customers Excellent problem
solving/troubleshooting skills Can stay much focused on the smallest details and ensure nothing is left to
chance Good at approaching a problem from multiple perspectives
Early Phase
Know the product vision/problem space Fully understand and document the key user scenarios
Learn about your customers Establish good relationships between disciplines and partner teams
Design before you code Research technologies and educate yourself
PM during early phase
This part of the project is driven by PMs Should start before the last phase in the previous cycle ends PMs
should be gathering user data, requirements, feedback, etc in order to plan next set of features Deliverables:
vision document, problem definition, high level feature list, user scenarios
Scenarios
Scenarios are end to end from the users perspective Important to really understand how users will interact
with the system and to understand end to end requirements/dependencies
Scenarios should be developed with and reviewed by real users Scenarios should drive feature list
Automated User Feedback
PM team should work with engineering team to build in mechanisms to provide automated user feedback
Query Logs/Click through Data SQM/Watson Verbose User Feedback
Feature List
An ordered list of features that may be built during this development cycle Engineering team (dev/test)
provide bottom up estimates for all features (week or month resolution) Feature list should include impact
Primary planning document for scoping/resource allocation
Dev during early phase
Supporting bug fixes for previous cycle Training and skill development for next cycle Research new
technologies, prototyping around core technology problems for next cycle Stay connected to PM team during
planning Post-mortem from last cycle
Test during early phase
Completing last phase of previous cycle Training and skill development for next cycle Research new
technologies, prototyping around core technology problems for next cycle Stay connected to PM team during
planning Post-mortem from last cycle
Middle Phase
Divided into major milestones (M1, M2, `etc.) Each milestone is a mini-release A set of features delivered
on a certain date Phases
Planning and design Implementation Stabilization and Integration Post-Mortem
PM during middle phase
Completing Solution Framework/Solution Specification Finalizing feature list Managing project details
(status, risk, etc.)
Solution Specification
Well articulated Problem Definition Document Solution Framework so everyone on the project team is
making decisions in the same way One line description of all features Full specs for all features planned for
the first milestone
Dev during middle phase
This part of the project is driven by Dev Developing design documents Writing code, unit testing,
debugging Deliverables: Quality code!
Unit Testing
Developers are responsible for testing their own code, to ensure that it works within local constrains and can
be checked in without breaking other code
Unit testing can and should be automated to provide regression testing for old features during changes
Code Complete
Target date for completing all features for this milestone Feature should be unit tested, checked in, integrated
with other code, BVTs pass Shift focus from quality at a local level to quality at a global level Focus on
stabilizing, not adding new Features
Source Code Control
Used to manage all source code necessary to build the system Enables version control, roll-back, merging,
branching Automated system to build the software from source code Automated system to verify new code
didnt break existing functionality, regression testing
Page 292

Code Reviews
Every line of code should be reviewed by peers before declaring code complete Great coaching/mentoring
opportunity for junior engineering staff Good mechanism to ensure architectural continuity Ensure quality at
an early stage in project Test during middle phase Developing automated test frameworks to ensure quality
end to end functionality, system performance, scalability Tracking defect rates to alert team to quality
problems Deliverables: Test automation
Defect Tracking
Necessary to track every defect that is detected after a piece of code is declared code complete
Triage used to determine which defects to fix, which to punt, how to resolve Bug Jail used to prevent
quality from getting out of control
Three Disciplines, Three Tools
Program Manager Feature List, Automated User Feedback
Developer Source Code Control System, BVT
Tester Defect Tracking System
Late Phase
End game! Stabilize, tightly manage any changes All changes are linked to defects or design change
requests Everyone should be focused on shipping
PM during late phase
Working with test on driving triage Writing specs for design change requests Making sure no details are
overlooked Starting to think about next cycle
Triage
Triage is usually driven by either senior tester or senior PM During the end phase of a project all defects
should be reviewed by triage team Determine which defects should be fixed Determine how defects will be
resolved
Not all bugs are worth fixing!
1. When this bug happens, how bad is the impact? (Severity) 2. How often does this bug happen? (Frequency) 3.
How much effort would be required to fix this bug? (Effort) 4. What is the risk of fixing this bug? (Risk)
Dev during late phase
Fixing high priority defects Participating in triage Helping test with integration, performance, scalability
testing Test during late phase The part of the project is driven by Test Focused on measuring/tracking quality
by looking at defect rates/severity Manage alpha, beta and dog food releases Use triage to manage all
changes after code complete Deliverables: Decision to ship!
Three disciplines, three deliverables
Program Management Problem definition, feature list, solution specification Development Quality code
that meets solution specification Testing Deciding when to ship [27]
5.
Safety, Security and Risk Management Aspect in SDLC
There are many different SDLC models and methodologies, but each generally consists of a series of defined
steps or phases. For any SDLC model that is used, information security must be integrated into the SDLC to
ensure appropriate protection for the information that the system will transmit, process, and store. [28]
The System Development Life Cycle.
Applying the risk management process to system development enables organizations to balance requirements
for the protection of agency information and assets with the cost of security controls and mitigation strategies
throughout the SDLC. Risk management processes identify critical assets and operations, as well as systemic
vulnerabilities across the organization. Some of the benefits of integrating security into the system development
life cycle include:
Page 293

Initiation Phase:
During the initiation phase, the organization establishes the need for a system and documents its purpose.
Security planning should begin in the initiation phase with the identification of key security roles to be carried
out in the development of the system. The information to be processed, transmitted, or stored is evaluated for
security requirements, and all stakeholders should have a common understanding of the security considerations.
Early planning and awareness will result in savings in costs and staff time through proper risk management
planning. In this phase, the organization clearly defines its project goals and high-level information security
requirements, as well as the enterprise security system architecture.
Development/Acquisition Phase:
During this phase, the system is designed, purchased, programmed, developed, or otherwise constructed. A key
security activity in this phase is conducting a risk assessment and using the results to supplement the baseline
security controls. In addition, the organization should analyze security requirements; perform functional and
security testing; prepare initial documents for system certification and accreditation; and design the security
architecture.
The developmental testing of the technical and security features and functions of the system ensure that they
perform as intended, prior to launching the implementation and integration phase.
Implementation Phase:
In the implementation phase, the organization configures and enables system security features, tests the
functionality of these features, installs or implements the system, and obtains a formal authorization to operate
the system. Design reviews and system tests should be performed before placing the system into operation to
ensure that it meets all required security specifications.
The results of the design reviews and system tests should be fully documented, updated as new reviews or tests
are performed, and maintained in the organizations official records.
Operations/Maintenance Phase:
In this phase, systems and products are in place and operating, enhancements and/or modifications to the system
are developed and tested, and hardware and software components are added or replaced. The organization
should continuously monitor performance of the system to ensure that it is consistent with pre-established user
and security requirements, and that needed system modifications are incorporated.
Configuration management (CM) and control activities should be conducted to document any proposed or actual
changes in the security plan of the system.
Disposal Phase:
In this phase, plans are developed for discarding system information, hardware, and software and making the
transition to a new system. The information, hardware, and software may be moved to another system, archived,
discarded, or destroyed.
The removal of information from a storage medium, such as a hard disk or tape, should be done in accordance
with the organizations security requirements.
Additional Security Considerations
Some IT development projects are service-based and may involve other organizations, such as public-private
sector supply chain endeavours. Other projects are facility-oriented, such as the establishment of a data centre or
a hot site. Organizations developing projects such as these should follow the principles for integrating security
into the SDLC, as they examine and address the additional security considerations involved in these projects.
[28]
6.
Conclusion
The AM is one of the best choice for design a software. ASDP is process to handle the disruptive software
Environment by incorporating practices and principles established in 2001. It has been observed that agile
practices such as delivering working software, short iterations and feedback etc. increase the internal and
external software quality. Some practitioners stated that agile practices are collection of best practices of the
software development. Although, there are many success stories of ASDP in last decade, but knowledge of
implementing these practices in a particular project is very scared. Therefore, we have analyzed software
development life cycle of all existing AMs and proposed a generalized ASDLC. Proposed ASDLC is essence of
all existing AMs and represents all phases required in a software development cycle in iterative and incremental
manner. It also encourages the practices of simple design, refactoring to maintain the simplicity.
ASDLC is a step towards resolving the misconceptions about AMs that these methods are adhoc coding
practices. A systematic approach to define all the phases of ASDP that is useful to average project manager to
understand the principles and practices behind agility. Feedback in ADCT phase improves internal quality
whereas feedback in iteration planning improves external quality of the product. Thus, proposed ASDLC is a
step towards improving agile software development which will leads to fast accessibility of AMs. However, this
is preliminary work and needs verification on large projects.
The proposed work can be summarized as the creation of the approach SDLC to develop software more
efficiently. The aim of Software Engineering is to develop software of high quality within budget and schedule.
Page 294

7.
Reference:
1.
K. K. Aggarwal, Yogesh Singh Software Engineering 3rd Edition.
2.
Naresh Kumar, A. S. Zadgaonkar, Abhinav Shukla, International Journal of Soft Computing and
Engineering (IJSCE) ISSN: 2231-2307, Volume-3, Issue-1, March 2013
3.
Dr.Deepshikha
JamwalAnalysis of
software Development
Models,
ISSN: 22294333(print),ISSN:09768491(online), vol.1ISSUE 2, Decemder 2010.
4.
Chan, D.K.C. Leung, K.R.P.H, Software development as a workflow process, 2-5 Page(s): 282
291, Dec. 1997.
5.
Kushwaha ety.al, Software Development Process and Associated Metrics - A Framework, IEEE
CNF, Page(s):255 260, July 2006.
6.
Rothi, J.,Yen, D, "System Analysis and Design in End User Developed Applications", Journal of
Information Systems Education, 1989
7.
Boehm, B. W. A Spiral Model of Software Development and Enhancement, ISSN: 0018-9162,
Volume: 21, Issue: 5, on page(s): 61-72, May 1988.
8.
Swapanja Ingale Comparative Study Of Software Development Model International conference on
advances in computing &management 2012
9.
Jovanovich, D., Dogsa, T. Comparison of software development models, Proceedings of the 7th
International Conference on, 11-13 June 2003, ConTEL 2003, pp. 587-592.
10.
Maglyas, A.; Nikula, U.; Smolander, K.,Comparison of two models of success prediction in software
development projects, Software Engineering Conference (CEE-SECR), 2010 6th Central and Eastern European
on 13-15 Oct. 2010, pp. 43-49.
11.
A. M. Davis, H. Bersoff, E. R. Comer, A Strategy for Comparing Alternative Software Development
Life Cycle Models, Journal IEEE Transactions on Software Engineering ,Vol. 14, Issue 10, 1988
12.
Sanjana Taya Comparative Analysis of Software Development Life ISSN:22294333(print),ISSN:0976- 8491(online),vol.2ISSUE 4,Oct-Dec2011
13.
Molokken-Ostvold et.al, A comparison of software project overruns - flexible versus sequential
development models,Volume 31, Issue 9, Page(s): 754 766, IEEE CNF, Sept.2005.
14.
S. M. Metev and V. P. Veiko, Laser Assisted Microtechnology, 2nd ed., R. M. Osgood, Jr., Ed. Berlin,
Germany: Springer-Verlag, 1998 Volume 2, Issue 5, May 2012 www.ijarcsse.com
15.
Ms. Shikha maheshwari1, Research Scholar in Dept.of C.S.E. Reader, S.V.I.T.S, Indore(M.P)
shikhamaheshwari0906@gmail.com
16.
Prof.Dinesh Ch. Jain2, S.V.I.T.S,Indore, dineshwebsys@gmail.com.
17.
Aoyamma, M., Agile Software Process and its Experiences, In IEEE, Transaction 1999.
18.
Abrahamsson, P., Salo, O., Ronkainen, J., and Warsta, J., Agile SoftwareMethods Rreview and
Analysis, Espoo, Finland: Technical Research Centre of Finland, VTT publication 478 available http://www.
inf. .fi /pdf/ publications /2002/478.pdf.2002
19.
Abrahamsson, P., Salo, O., Ronkainen, J., and Warsta, J., New Directions on Agile Methods : A
Comparative Analysis, In Proceeding of 25th International conference on Software engineering 2003.
20.
Beck, K., Extreme Programming Explained, Pearson Education Low price Edition Asia.
21.
Bergin, J., and Grossman, F., Extreme Construction: Making Agile Accessible, In Proceedings of
IEEE Agile 2006 Conference.
22.
Bhalerao, S., and Ingle, M., Formalizing Communication Channel in Agile Methods, In Proceedings
of International Conference on Trends in Information Science and Computing (TISC07), Dec. 2007.
23.
Bhalerao, S., and Ingle, M., Mapping SDLC phase with Various Agile Methods, In Proceedings of
International conference on Advances in Computer Vision and information Technology, Nov. Aurangabad, pp.
318-325.
24.
Cohn, M., and Ford, D., Introducing an Agile Process to an Organization, In IEEE Computer Society
2003, pp.74-78.
25.
Bhalerao, S., and Ingle, M., A Comparative Study of Agile Projects
26.
M.Ingle, International Journal on Computer Science and Engineering Vol.1(3), 2009, 222-226, School
of computer Science and Information , Technology, Devi Ahilya University, Indore, India,
aya_ingle@rediffmail.com
27.
Software Development Lifecycle, Steve Macbeth, Group Program Manager, Search Technology
Center, Microsoft Research Asia.
28.
THE SYSTEM DEVELOPMENT LIFE CYCLE (SDLC) Shirley Radack, Editor Computer Security
Division Information Technology Laboratory National Institute of Standards and Technology.
Page 295

Road Map To Design Successful Software - Ictms (Integrated Clinical Trial Management System)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Road Map To Design Successful Software - Ictms (Integrated Clinical Trial Management System)

Uploaded by

Copyright:

Available Formats

INTERNATIONAL JOURNAL OF EMERGING TECHNOLOGIES AND

APPLICATIONS IN ENGINEERING, TECHNOLOGY AND SCIENCES (IJ-ETA-ETS)