1Q) Information Systems (IS) Projects

The scope and magnitude of the functional and procedural changes may be fairly narrow or wide ranging.
In some cases, aside from re-coding the system, there may be no changes in functionality at all.

Given the variety of reasons for a project being undertaken, the starting point may also be quite different
from project to project. These starting points reflect the differences in current user processing
environments and the current level of user automation. Because of these differences in current user
processing environments and user automation, information systems projects can be categorized into three
types.

1. Manual
2. Manual to automated
3. Re automation
4. The last, re automation, has four subtypes.

a) System rewrite
b) System redesign and redevelopment
c) System enhancement
d) System maintenance

From an analysis perspective, each of these types of projects involves different, and yet similar, work.
The work is similar in that the development activities, which are involved in each, follow the same
general phases and approach. They are different in that each of the starting or current environments that
the analyst must examine have substantially different characteristics. Briefly, these six environmental
types and subtypes are as follows.

Manual

The analyst's task in the manual environment is to simplify the work flows, streamline the processes,
reduce redundant processing, rearrange the tasks so as to ensure more orderly processing, and ensure that
the forms, documents, and reports contain all necessary data. Each task, and each task step, must be
examined to determine (a) if its execution is appropriate and (b) if it is appropriately defined, positioned,
and performed.

The results of the analysis of manual systems are usually new or revised standards and procedures which
clearly define the processing sequence for the task to be performed and the rules which govern their
performance. In addition the analyst may develop new input forms, control procedures, monitoring
procedures, and reports. The output from the analysis may also include new or revised work and data flow
diagrams.

Manual to automated

Working in this type of environment differs from working in the strictly manual environment in that the
analyst's task is to determine whether the manual environment, in whole or in part, can be augmented by
automation, and if so, to what extent. The existing environment must be analyzed in the same manner as
the purely manual, but as the analysis progresses, the analyst must also find ways of substituting
automated processing for manual processing. To accomplish this, the analyst must break each process and
task into its component steps and determine if the rules for performing the step lend themselves to
machine automation.
The analyst's output for this type of project closely resembles that produced from the strictly manual
project. However, here the analyst must also develop (a) new, input forms suitable to an automated
environment, (b) file content requirements for ongoing master and transaction files, (c) report layouts, and
(d) a processing flow which intermixes the original and unmodified manual processes, new manual
processes, and new automated processes. The analyst must also make a determination as to the costs
involved in the automation process, provide project schedules, and make hardware and software analyses
and recommendations.

Reautomation

There have been many attempts to set down analytical and design methodologies for development
projects in automated environments. What many of them ignore is that there are different types of
automated business environments, which, while seemingly similar, must in fact be treated differently.

What distinguishes these environments is the extent and depth of automation. Early analysis
methodologies were predicated on a manual environment. The aim of the analysis was to develop an
automated solution to user business problems. In today's environment, most firms of any size have
existing levels of automation. Many in fact have gone through two and three rounds of automation and
reautomation.

Many of the existing processes and procedures are either totally automated or were developed as a result
of a partial automation of the user area. Many of the forms and transaction flows within this type of
environment are automated or semi-automated.

This prior automation poses a trap for the unwary analyst in that the currently used forms and documents
of the business may in fact have been designed to support and accommodate an automated system. These
automated systems may have been designed for the business using a level of technology which is now
outdated or inefficient, or for a set of user requirements or a business environment which has since
become wholly or partially obsolete. Additionally, these forms and documents are the result of some prior
analyst's efforts and may not in fact reflect the natural information or data needs of the firm.

The processing flows themselves may be unnatural, to the extent that they reflect the intrusion of
automated processing sequences. These flows may have been structured to accommodate the needs of the
then prevalent technology rather than the needs of the business. Each of the documents, transactions and
process flows must be reexamined in the light of the current business environment and the current
business processing needs. They may merely need to be refurbished, or they may need to be scrapped
entirely in favor of a new and more streamlined processing flow.

The analyst must look with care on batch flows, "processing windows," and transaction holding queues.
These constraints may have been imposed on the processing environment by the requirements of prior
automation efforts, most probably implemented under what is now an outdated, or, worse, obsolete
technology. Reautomation is a major type of project which incorporates the following sub-categories.

System rewrite.

The "system rewrite" is one of the simplest forms of reautomation. A system rewrite usually involves
very little analysis of the current business environment and thus entails very little change to that
environment from the aspect of functionality or procedure. It is closely allied with system maintenance in
that the goal is not to change the processing flows or to add to system functionality but simply to "clean
up" the processing, streamline the existing flows, or rewrite the programs in a more up-to-date language
or with more up-to-date file handling technology.

As part of the rewrite process, file layouts, report layouts, screens, and transactions may change, but
usually the file and report content do not, and neither does the user processing environment. A rewrite
may remove processing anomalies ("bugs"), remove unused, obsolete, or outdated code and may
add minor new functionality to the system. The emphasis here is on minor.

System rewrites are usually done for the benefit of, and are initiated by, the data processing community,
either the data processing system developers and system maintenance personnel who need a "cleaner"
system to maintain, or the data processing operations personnel who have requested operational changes
to streamline the processing or to make it more efficient.

System enhancement and maintenance.

Although the two sub-categories are usually separated, they are sufficiently similar, from an analysis
viewpoint, to be examined together. Applications maintenance and enhancement projects differ from
development projects in one substantial way: The analysis and design personnel assigned to these projects
must also assess the impact of the proposed change on an existing system.

These maintenance or enhancement projects usually leave large parts of the base system intact. The
remaining parts are either modified or "hooks" are added to the additional code which support the added
functionality. The requests for maintenance or enhancement changes normally originate with the user,
although they may originate with the development team itself.

There are numerous reasons for these system modification requests; among them are changes to the
business environment, user-requested additional functionality, correction of erroneous processing, and
user-requested refinements, or cosmetic changes to the existing system.

Those changes which originate from alterations to the business environment are the most difficult to
implement, followed closely by those which add new functionality. The implementation difficulties arise
because these types of changes not only require new analysis of the user area but also re-analysis of the
original system design to determine where and how the changes can and should be made. Maintenance or
enhancement which is necessitated by correction of erroneous processing, user-desired refinements, or
other cosmetic changes usually requires little in the way of new analysis.

The analysis and redesign efforts required by business environment changes and additions of new
functionality can be almost as extensive as those which were required in the original systems
development. The most difficult aspects of changing an application system are those which are directed
either toward changes in underlying system design and the resulting processing logic, or toward changing
the structure and contents of the system files or database.

When the maintenance or enhancement project is directed at a system in a database environment and the
database must be changed, the analysis must not only cover the application in question, but also any other
applications which use the same database and in particular the same data records or data elements.

In some cases, the immediate enhancement or maintenance project will require data which should
logically be captured by a different, unrelated application. The "chain reaction" or "cascade" of changes
can increase the scope and impact of the initial request by orders of magnitude. Use of database
technology encourages integrated and interdependent systems designs. The greater the integration or
interdependence, the greater the potential impact of any change.

The most difficult of these data-directed changes occurs when the structural logic of the database must be
modified. Even minor changes here can have major impact. The more extensive the use of the database,
the more thorough and painstaking the analysis that is required. Reporting, retrieval, or other file access
facilities may be severely impacted by these data structure, content, or processing logic changes.

System redesign and redevelopment.

The system redesign and redevelopment project is the most comprehensive and difficult type of
reautomation. It involves not only the traditional activities of the "new" development project but also the
additional activities of file conversion.

The system redesign and redevelopment requires a start-from-scratch analysis, which must at the same
time acknowledge the presence of the existing system. This type of project is usually undertaken when an
organization "migrates" from one hardware or software technology to another.

The newness of the technology requires that the existing hardware and/or software base be replaced. In
some cases the business environment has changed so substantially, either for competitive or internal
restructuring reasons, that the old systems can no longer service the business. The internal restructuring
may have resulted from a shift from a centralized to a decentralized environment, the addition of major
new lines of business, or a change in orientation of the firm, such as from an account to a customer
orientation, or from a sales force-based organization to a direct-mail-marketing organization. In some
more recent cases, this restructuring results from the firm's acquisition of other businesses or from the
acquisition of the firm by another business. In all cases, the internal automated systems need to be
redesigned and redeveloped to support the new environment.

2Q) System design strategies

A good system design is to organize the program modules in such a way that
are easy to develop and change. Structured design techniques help developers
to deal with the size and complexity of programs. Analysts create instructions
for the developers about how code should be written and how pieces of code
should fit together to form a program.
Software Engineering is the process of designing, building, testing, and
maintaining software. The goal of software engineering is to create software
that is reliable, efficient, and easy to maintain. System design is a critical
component of software engineering and involves making decisions about the
architecture, components, modules, interfaces, and data for a software system.
System Design Strategy refers to the approach that is taken to design a
software system. There are several strategies that can be used to design
software systems, including the following:
1. Top-Down Design: This strategy starts with a high-level view of the system
and gradually breaks it down into smaller, more manageable components.
2. Bottom-Up Design: This strategy starts with individual components and
builds the system up, piece by piece.
3. Iterative Design: This strategy involves designing and implementing the
system in stages, with each stage building on the results of the previous
stage.
4. Incremental Design: This strategy involves designing and implementing a
small part of the system at a time, adding more functionality with each
iteration.
5. Agile Design: This strategy involves a flexible, iterative approach to design,
where requirements and design evolve through collaboration between self-
organizing and cross-functional teams.

The choice of system design strategy will depend on the particular

requirements of the software system, the size and complexity of the system,
and the development methodology being used. A well-designed system can
simplify the development process, improve the quality of the software, and
make the software easier to maintain.

Importance :
1. If any pre-existing code needs to be understood, organized, and pieced
together.
2. It is common for the project team to have to write some code and produce
original programs that support the application logic of the system.
There are many strategies or techniques for performing system design. They
are:
 Bottom-up approach:
The design starts with the lowest level components and subsystems. By
using these components, the next immediate higher-level components and
subsystems are created or composed. The process is continued till all the
components and subsystems are composed into a single component, which
 is considered as the complete system. The amount of abstraction grows high
as the design moves to more high levels. 
By using the basic information existing system, when a new system needs to
be created, the bottom-up strategy suits the purpose.

Advantages:
 The economics can result when general solutions can be reused.
 It can be used to hide the low-level details of implementation and be merged
with the top-down technique.
Disadvantages:
 It is not so closely related to the structure of the problem.
 High-quality bottom-up solutions are very hard to construct.
 It leads to the proliferation of ‘potentially useful’ functions rather than the
most appropriate ones.
Top-down approach: Each system is divided into several subsystems and
components. Each of the subsystems is further divided into a set of subsystems
and components. This process of division facilitates forming a system hierarchy
structure. The complete software system is considered a single entity and in
relation to the characteristics, the system is split into sub-systems and
components. The same is done with each of the sub-systems. 
This process is continued until the lowest level of the system is reached. The
design is started initially by defining the system as a whole and then keeps on
adding definitions of the subsystems and components. When all the definitions
are combined together, it turns out to be a complete system. 
For the solutions of the software that need to be developed from the ground
level, a top-down design best suits the purpose. 
Advantages:
 The main advantage of the top-down approach is that its strong focus on
requirements helps to make a design responsive according to its
requirements.
Disadvantages:
 Project and system boundaries tend to be application specification-oriented.
Thus it is more likely that the advantages of component reuse will be missed.
 The system is likely to miss, the benefits of a well-structured, simple
architecture.
 Hybrid Design:
It is a combination of both top-down and bottom-up design strategies. In this,
we can reuse the modules.
Advantages of using a System Design Strategy:
1. Improved quality: A well-designed system can improve the overall quality of
the software, as it provides a clear and organized structure for the software.
2. Ease of maintenance: A well-designed system can make it easier to maintain
and update the software, as the design provides a clear and organized
structure for the software.
3. Improved efficiency: A well-designed system can make the software more
efficient, as it provides a clear and organized structure for the software that
reduces the complexity of the code.
4. Better communication: A well-designed system can improve communication
between stakeholders, as it provides a clear and organized structure for the
software that makes it easier for stakeholders to understand and agree on
the design of the software.
5. Faster development: A well-designed system can speed up the development
process, as it provides a clear and organized structure for the software that
makes it easier for developers to understand the requirements and
implement the software.

Disadvantages of using a System Design Strategy:

1. Time-consuming: Designing a system can be time-consuming, especially for

large and complex systems, as it requires a significant amount of
documentation and analysis.
2. Inflexibility: Once a system has been designed, it can be difficult to make
changes to the design, as the process is often highly structured and
documentation-intensive.

3Q) STRUCTURE CHART / SYSTEM DESIGN TECHNIQUES

The Structure Chart is a basic tool of Structured System Design. It is a graphic representation of
a hierarchy of modules and the relationships between them. In Section 2 two types of Structure
Charts were discussed; they were referred to as Structure Charts and Program Structure
Charts. The first type represents the detailed functional breakdown of the software without
taking packaging into account. The second type illustrates the actual programs and procedures
to be developed.

A Structure Chart represents system structure. It can also be used to illustrate

flow of information between modules. It does not illustrate flow of control; it does
not provide any information about sequencing of events or about condition tests.
The figure above provides an example of a Program Structure Chart. It illustrates the different
symbols which can be used. A box represents a module; lines connecting the modules
represent the calling hierarchy. Loops, conditional calls and parameters can also be illustrated
on the Structure Charts using the symbols shown. Illustrated parameter passing can become
messy and cumbersome; it may be preferable to describe the parameter passing in the Project
Encyclopaedia.

Data Flow Oriented Design

Data flow oriented decomposition is a method of deriving the modular design based on the data
flow diagram. It is the recommended method for processing oriented applications such as
Accounting, Payroll and Inventory.

The procedure is as follows.

1. Define the top level module.

2. Identify the major input streams, output streams, and the processing center. The processing
center can often be identified by parallelism of data flow (see Figure below where transactions
A, B, C are processed in parallel).

3. Define a module for each input or output stream and the processing center. For the
processing center, define a sub-module for each of the processes occurring in parallel.
4. For each of the lowest level modules, take the corresponding portion of the DFD and repeat
Step 2 and 3 until fully decomposed.
5. Refine the design to decrease the coupling and increase the cohesion of the modules. This is
necessary because DFD's do not take into account control flow, trivial data paths or packaging
considerations.
Data Structure Oriented Design
Data Structure Oriented Design is a technique of modular decomposition which transforms a
representation of a data structure into a representation of software.

This method can be used for systems with a well defined, hierarchical structure of information,
heavy input/output flow and little processing logic; e.g., a library catalogue system.

Object-Oriented Design
Object-Oriented Design is an approach to modular decomposition which views a problem in
terms of objects and operations and defines the solution in the same terms. It is applicable to
applications such as simulation systems, real time systems, and to systems with complex or
dynamic entities which are difficult to represent using traditional techniques.

This approach requires a language in which real world objects can be represented. These
languages typically build classes of an object in the application.

For each class, the attributes and properties that each object in the class shares are defined.
The actions which each object can perform are described. These are written in the form of
messages to which each object in the class can respond. As a result, all communication
between any two objects, whether they are from the same class or not, is performed by sending
messages. Thus, object-oriented languages have a very high degree of encapsulation, in that
each object is responsible for its own operation, and no other object may access its structure
directly. The net result is that each message is like a separate black-box, a property which
makes system design more manageable.

New classes are introduced as specializations or generalizations of existing classes. For

example, in a naval simulation system, a class SHIP could be introduced, and the attributes and
properties of a ship defined. Specializations of this class, such as FRIGATE and DESTROYER,
could then be introduced. These two new classes could inherit the properties of the class SHIP,
while defining those properties which makes them unique.

Many object-oriented languages are now becoming available, such as SMALLTALK, LISP
FLAVERS, Objective C, C++, ADA, and SIMULA.

4Q) Structured Analysis and Structured Design (SA/SD) is a diagrammatic

notation that is designed to help people understand the system. The basic goal
of SA/SD is to improve quality and reduce the risk of system failure. It
establishes concrete management specifications and documentation. It focuses
on the solidity, pliability, and maintainability of the system. 
Structured Analysis and Structured Design (SA/SD) is a software development
method that was popular in the 1970s and 1980s. The method is based on the
principle of structured programming, which emphasizes the importance of
breaking down a software system into smaller, more manageable components.
In SA/SD, the software development process is divided into two phases:
Structured Analysis and Structured Design. During the Structured Analysis
phase, the problem to be solved is analyzed and the requirements are
gathered. The Structured Design phase involves designing the system to meet
the requirements that were gathered in the Structured Analysis phase.

1. Structured Analysis and Structured Design (SA/SD) is a traditional software

development methodology that was popular in the 1980s and 1990s. It
involves a series of techniques for designing and developing software
 systems in a structured and systematic way. Here are some key concepts of
SA/SD: Functional Decomposition: SA/SD uses functional decomposition to
break down a complex system into smaller, more manageable subsystems.
This technique involves identifying the main functions of the system and
breaking them down into smaller functions that can be implemented
independently.
2. Data Flow Diagrams (DFDs): SA/SD uses DFDs to model the flow of data
through the system. DFDs are graphical representations of the system that
show how data moves between the system’s various components.
3. Data Dictionary: A data dictionary is a central repository that contains
descriptions of all the data elements used in the system. It provides a clear
and consistent definition of data elements, making it easier to understand
how the system works.
4. Structured Design: SA/SD uses structured design techniques to develop the
system’s architecture and components. It involves identifying the major
components of the system, designing the interfaces between them, and
specifying the data structures and algorithms that will be used to implement
the system.
5. Modular Programming: SA/SD uses modular programming techniques to
break down the system’s code into smaller, more manageable modules. This
makes it easier to develop, test, and maintain the system.
Some advantages of SA/SD include its emphasis on structured design and
documentation, which can help improve the clarity and maintainability of the
system. However, SA/SD has some disadvantages, including its rigidity and
inflexibility, which can make it difficult to adapt to changing business
requirements or technological trends. Additionally, SA/SD may not be well-
suited for complex, dynamic systems, which may require more agile
development methodologies.

The following are the steps involved in the SA/SD process:

1. Requirements gathering: The first step in the SA/SD process is to gather

requirements from stakeholders, including users, customers, and business
partners.
2. Structured Analysis: During the Structured Analysis phase, the requirements
are analyzed to identify the major components of the system, the
relationships between those components, and the data flows within the
system.
3. Data Modeling: During this phase, a data model is created to represent the
data used in the system and the relationships between data elements.
4. Process Modeling: During this phase, the processes within the system are
modeled using flowcharts and data flow diagrams.
5. Input/Output Design: During this phase, the inputs and outputs of the system
are designed, including the user interface and reports.
6. Structured Design: During the Structured Design phase, the system is
designed to meet the requirements gathered in the Structured Analysis
phase. This may include selecting appropriate hardware and software
platforms, designing databases, and defining data structures.
7. Implementation and Testing: Once the design is complete, the system is
implemented and tested.
SA/SD has been largely replaced by more modern software development
methodologies, but its principles of structured analysis and design continue to
influence current software development practices. The method is known for its
focus on breaking down complex systems into smaller components, which
makes it easier to understand and manage the system as a whole.
Basically, the approach of SA/SD is based on the Data Flow Diagram. It is
easy to understand SA/SD but it focuses on well-defined system boundary
whereas the JSD approach is too complex and does not have any graphical
representation. 
SA/SD is combined known as SAD and it mainly focuses on the following 3
points:
1. System 
2. Process 
3. Technology 
SA/SD involves 2 phases:  
1. Analysis Phase: It uses Data Flow Diagram, Data Dictionary, State
Transition diagram and ER diagram. 
2. Design Phase: It uses Structure Chart and Pseudo Code. 
 
1. Analysis Phase: 
Analysis Phase involves data flow diagram, data dictionary, state transition
diagram, and entity-relationship diagram. 
1. Data Flow Diagram: 
In the data flow diagram, the model describes how the data flows through
the system. We can incorporate the Boolean operators and & or link data
flow when more than one data flow may be input or output from a process. 
For example, if we have to choose between two paths of a process we can
add an operator or and if two data flows are necessary for a process we can
add an operator. The input of the process “check-order” needs the credit
information and order information whereas the output of the process would
be a cash-order or a good-credit-order. 
 
2. Data Dictionary: 
The content that is not described in the DFD is described in the data
dictionary. It defines the data store and relevant meaning. A physical data
dictionary for data elements that flow between processes, between entities,
and between processes and entities may be included. This would also
include descriptions of data elements that flow external to the data stores. 

A logical data dictionary may also be included for each such data element.
All system names, whether they are names of entities, types, relations,
attributes, or services, should be entered in the dictionary. 
 
3. State Transition Diagram: 
State transition diagram is similar to the dynamic model. It specifies how
much time the function will take to execute and data access triggered by
events. It also describes all of the states that an object can have, the events
under which an object changes state, the conditions that must be fulfilled
before the transition will occur and the activities were undertaken during the
life of an object. 
 
4. ER Diagram: 
ER diagram specifies the relationship between data store. It is basically used
in database design. It basically describes the relationship between different
entities. 
2. Design Phase: 
Design Phase involves structure chart and pseudocode.  
1. Structure Chart: 
It is created by the data flow diagram. Structure Chart specifies how DFS’s
processes are grouped into tasks and allocated to the CPU. The structured
chart does not show the working and internal structure of the processes or
modules and does not show the relationship between data or data flows.
Similar to other SASD tools, it is time and cost-independent and there is no
error-checking technique associated with this tool. The modules of a
structured chart are arranged arbitrarily and any process from a DFD can be
chosen as the central transform depending on the analysts’ own perception.
The structured chart is difficult to amend, verify, maintain, and check for
completeness and consistency.  
2. Pseudo Code: It is the actual implementation of the system. It is an informal
way of programming that doesn’t require any specific programming language
or technology. 

Advantages of Structured Analysis and Structured Design (SA/SD):

1. Clarity and Simplicity: The SA/SD method emphasizes breaking down
complex systems into smaller, more manageable components, which makes
the system easier to understand and manage.
2. Better Communication: The SA/SD method provides a common language
and framework for communicating the design of a system, which can
improve communication between stakeholders and help ensure that the
system meets their needs and expectations.
3. Improved maintainability: The SA/SD method provides a clear, organized
structure for a system, which can make it easier to maintain and update the
system over time.
4. Better Testability: The SA/SD method provides a clear definition of the inputs
and outputs of a system, which makes it easier to test the system and
ensure that it meets its requirements.

Disadvantages of Structured Analysis and Structured Design

(SA/SD):

1. Time-Consuming: The SA/SD method can be time-consuming, especially for

large and complex systems, as it requires a significant amount of
documentation and analysis.
2. Inflexibility: Once a system has been designed using the SA/SD method, it
can be difficult to make changes to the design, as the process is highly
structured and documentation-intensive.
3. Limited Iteration: The SA/SD method is not well-suited for iterative
development, as it is designed to be completed in a single pass.

5Q) Techniques of vendor evaluation

Choosing a vendor for IT outsourcing services is a major commitment. But it

may be hard to see through the loud marketing of software development
companies, most of whom have professional developers, great portfolios, and
years of experience. 

Unfortunately, it’s not that rare for a seemingly good company to deliver bad
code, implement the wrong software, or create good software but implement it
incorrectly. Sometimes, code and integrations work well at first, but then you
discover that your software is inflexible and hard to maintain when you try
adding new features. 

Top 8 Vendor Evaluation Criteria

As a business has evaluated its project, it’s time to find an outsourcing

vendor.

1. Expertise and Qualifications

There’s nothing more important when selecting your software

outsourcing partner than evaluating its expertise and qualifications. By
specifying a tech stack and skill set requirements, you can significantly
cut the number of potential vendors at the very first step.

Determine the top 3 technical skills your software requires and

set them as top priorities in your vendor evaluation criteria. Focus on
the technical expertise that has the greatest positive impact on user
experience and the overall quality of your future software. No two
projects are the same, but if they’ve covered projects similar to yours,
that’s a good indicator that they clearly understand what it takes to
deliver your project successfully, as well.

2. Industry Experience
Everything said about the tech knowledge is also valid for evaluating a
vendor’s industry experience. Software service providers who have
spent years in the specific business vertical will have built up subject-
matter expertise that is invaluable to you.

That’s not to say that a vendor can’t learn about your industry. But it
does mean it will take a lot longer for them to get up to speed. If you
want to ramp up your efforts quickly, it makes sense to look for a
vendor who already knows your domain and can hit the ground
running.

3. Team Size

Before approaching a technology partner, you should define the

approximate scope of your project. If your project is estimated under
500 hours to complete, it’s better to hire freelancers. If your project is
much more complicated, you can choose from three types of software
outsourcing companies: small, medium, and large. Here we gathered
the main pros and cons of each category.

One of the critical aspects affected by the vendor’s size is its ability to
scale the development team up or down. Medium and large size
vendors have more internal resources and a bigger external pool of
candidates. So they can easily extend the development team to handle
the increasing workload and rotate people to a different project if you
need to ramp down.

4. Pricing and Engagement Models

Start from analyzing the vendor’s average hourly rates (by seniority
and job specialization). Compare it to the average in the region. Then,
provide the vendor with the scope of your future project and ask him to
configure a ‘virtual’ team of specialists with the required qualification
needed to deliver it. Ask about discounts and special offerings.

You should clearly understand the scope of your project and your final
goal. In fact, the budget of the project is determined by the engagement
model you choose (fixed price, time & material, dedicated team).
Choose the engagement model that suits you best and then calculate.

5. References and Recommendations

Nothing talks better about how well a vendor treats the clients than
clients themselves. Nowadays, it is a common practice to request
references, and companies are usually open to giving feedback, of
course, without revealing project details placed under NDA. Ask a
potential technology partner to provide contacts of product owners,
project managers, or C-suite executives representing their current and
past clients. Their feedback might reveal genuine insights about the
vendor’s service quality, work processes, communication style, and
even cultural nuances.
6. Communication

As English is the de facto language of communication in the tech

world, it goes without saying that a software development company
should have a conversational English proficiency level. While the
intermediate level can be acceptable for junior and middle specialists,
senior team members should clearly and immediately understand all
client’s requirements, claims, and suggestions. So they must be fluent
in English.

Another key aspect is communication frequency and transparency,

which is extremely important from the beginning and throughout your
outsourcing relationship. Expect to use weekly video conference calls,
regular emails, and instant messages every day. Frequent status
reports will help ensure that your engineers are working on the most
critical tasks.

7. Location and Time Zone

A convenient geographical location is a vital criterion every business

should consider while looking for a technology partner. Short flight
distance, small-time difference, and visa-free travel can significantly
cut management and administrative costs.

There are several popular outsourcing locations across the world

(including South/Latin America, South East Asia, India), but engineers
from Eastern Europe moved to lead positions due to their ability to
produce top-notch software without compromises. The region is well-
known for its density of software developers, which is 1.3
developers per 100 people.

8. Intellectual Property and Data Security

Preserving your Intellectual Property, idea, and rights is crucial when it

comes to software outsourcing. On the evaluation stage, you must
explore the legal practices and formal agreements the vendor uses to
ensure that your intellectual property and company are fully protected.
Here is the list of subjects you should review and negotiate with a
technology partner:

 Non-Disclosure Agreement (NDA). NDA is a fundamental

measure that protects your idea from disclosing it to a third
party. For UpsilonIT, an NDA is a must. It can be signed either
before a client reveals anything about his idea or before the
project kicks off. An NDA protects your vision also after the
project ends.

 IP Rights. The agreement you sign with a vendor must state

that your company gains exclusive ownership of the code,
product itself, and assets like designs, wireframes,
documentation, and diagrams.

 Non-Employment Agreement (NEA). A non-employment

agreement is a protection for both sides. On the one hand, a
 company won’t recruit or hire any of your employees. On the
other hand, you won’t do the same for them.

 Data privacy. This add-on makes you sure that the vendor

guarantees the safety and security of your data during every
stage of the project, from exchanging information at the project
outset to storing it after the project has been completed.

As you can see, choosing the right outsourcing tech partner is not so
obvious and simple. The evaluation process includes both quantitative
and qualitative assessments and is not limited to the criteria discussed
above: you can analyze additional factors that matter most to your
product and business goals.

Once you’ve received the information from your initial list of vendors,
it’s time to compile it in one place and make comparisons.