MBA - II

Prepared by Waleed Shah

[COMPUTER ASSINGMENT]
System development life Cycle and difference between In-House and Out Source
COMPUTER ASSINGMENT MBA - II

2


System Development Life Cycle (SDLC)
In systems development, the temptation to skip certain prescribed tasks associated
with documentation, combined with the fastpaced life of IT professionals, can create an
environment that is not able to properly employ the best practices of systems
development. However, the employment of best practices has proven over the years to
provide returns in both efficiencies and effectiveness.
In all types of audit, the employment of any set of best practices is generally seen by
auditors as a positive impact on the quality of the information, systems or operations
being audited. In the case of the systems development life cycle (SDLC), some practices
provide additional benefits in terms of IT audits. Specifically, throughout the steps in
the SDLC, documentation is being created that provides valuable potential sources of
evidence for IT auditors. In other words, employing SDLC as it is prescribed in the
industry is a control.
In this article, the conventional phases of the SDLCand how each one can provide this
potential evidencewill be discussed. Different groups use different lists of steps in the
SDLC, but almost all agree on the same elements. Herein, a list of eight phases is used
to demonstrate this process of analyzing an entitys SDLC. A summary of six of the eight
phases and examples of related documentation are depicted in figure 1. Other
documentation should exist; those contained in the figure are for illustrative purposes.
Phase One: Systems Planning
In phase one, systems are planned using a strategic approach. Executives and others
evaluate the effectiveness of systems in terms of meeting the entitys mission and
objectives. This process includes general guidelines for system selection and systems
budgeting. Management develops a written long-term plan for systems that is strategic
in nature. The plan will change in a few months, but much evidence exists that such
planning pays dividends in terms of effective IT solutions over the long term.
This phase is similar to IT governance, and the two are quite compatible. Thus, the first
thing an IT auditor would like to see is the implementation of IT governance activities.
During this phase, several documents will be generated. They include the long-term
plan, policies for selection of IT projects, and a long-term and short-term IT budget, as
well as preliminary feasibility studies and project authorizations. Project proposals
should have been documented when submitted to management, and a project
schedule should exist that contains the approved projects (see figure 1).
COMPUTER ASSINGMENT MBA - II

3



The presence of these documents illustrates a structured, formal approach to systems
development and, as such, illustrates an effective planning system for IT projects and
systems. It also demonstrates a formal manner of approving IT projects.
IT auditors will want to verify the presence of a systems planning phase (or IT
governance activities) and take a sample of the documents to verify the effectiveness of
that system. The same audit procedure will be true for all of the other seven phases
and, therefore, will not be repeated in the narratives of phases two through eight.
Phase Two: Systems Analysis
In the systems analysis phase, IT professionals gather information requirements for the
IT project. Facts and samples to be used in the IT project are gathered primarily from
end users. A systems analyst or developer then processes the requirements, producing
a document that summarizes the analysis of the IT project.
The result is some kind of documentation, such as a systems analysis report (see figure
1). Other documentation should exist. In effect, systems analysis illustrates the entitys
ability to be thorough with its systems development.
Phase Three: Conceptual Design
Next comes the conceptual design phase. In phase two, systems analysis, the
requirements have been gathered and analyzed. Up to this point, the project is on
paper and each user group has a slightly different view of what it should be. At this
point, a conceptual design view is developed that encompasses all of the individual
views.
COMPUTER ASSINGMENT MBA - II

4


A variety of possible documents could be the output of this phase. Figure 1 uses a data
flow diagram (DFD), developed to a general level at this point, as an example. The point
is that one or more of these documents should exist if the entity is following the SDLC
thoroughly.
Phase Four: Systems Evaluation and Selection
During the systems evaluation and selection, managers and IT professionals choose
among alternatives that satisfy the requirements developed in phases two and three,
and meet the general guidelines and strategic policies of phase one.
Part of the analysis of alternatives is to do a more exhaustive and detailed feasibility
studyactually, several types of feasibility studies. A technical feasibility study
examines whether the current IT infrastructure makes it feasible to implement a
specific alternative. A legal feasibility study examines any legal ramifications of each
alternative. An operational feasibility study determines if the current business
processes, procedures and skills of employees are adequate to successfully implement
the specific alternative. Last, a scheduled feasibility study relates to the firms ability to
meet the proposed schedule for each alternative. Each of these should lead to a written
feasibility report.
Another aspect of this phase is a cost-benefit analysis. Quantifying tangible and
intangible costs and benefits, an accountant should be able to determine the value of
each alternative. This phase is associated with how to assess the value of IT.
Finally, since a definitive choice among alternatives is being made, a selection report
should be written to explain the reasons behind the choice and, possibly, include the
costbenefit and feasibility studies.
Phase Five: Detailed Design
At this point, IT professionals have chosen the IT solution. The DFD design created in
phase three is fleshed out; that is, details are developed and (hopefully) documented.
Examples of the types of documentation created include use cases, Unified Modeling
Language (UML) diagrams, entity relationship diagrams (ERDs), relational models and
normalized data diagrams. Other systems design documents could also exist. IT
professionals often do a walk-through of the software or system to see if any defects in
the system can be detected during development. That walk-through should also be
documented.
To summarize this phase, a detailed design report should be written to explain the
steps and procedures taken. It would also include the design documents referred to
previously.

COMPUTER ASSINGMENT MBA - II

5


Phase Six: Programming and Testing Systems
For in-house development of applications, current best practices include the use of
object-oriented (OO) programs and procedures. IT auditors should be interested in the
IT programming shops choice of tools and procedures. Some businesses are locked into
legacy systems and applications and, thus, would not be expected to use OO (e.g.,
banks). IT auditors would also be interested in programming flow charts as
documentation.
No element of SDLC is more important than systems testing. Perhaps none of the
phases has been more criticized than testing for being absent or performed at a
substandard level. Sometimes management will try to reduce the costs of an IT project
by cutting out or reducing the testing.
Sound testing includes several key factors. The testing should be done offline before
being implemented online. Individual modules should be tested, but even if a module
passes the test, it should be tested in the enterprise system offline before being
employed. That is, the modules should be tested as stand-alone and then, in
conjunction with other applications, tested systemwide. Test data and results should be
kept, and end users should be involved in the testing.
Figure 1 does not include this phase, but clearly the test results should be documented.
The IT auditor will want to gain some assurance that proper testing of applications and
systems has occurred before they are being put into operations.
Phase Seven: Systems Implementation
At this point, the system should be ready to deploy. The last step before deployment is
a user acceptance sign-off. No system should be deployed without this acceptance. The
user acceptance report should be included in the documentation of this phase.
After deployment, however, the SDLC processes are not finished. One key step after
implementation is to conduct a postimplementation review. This reviews the cost-
benefit report, traces actual costs and benefits, and sees how accurate the projections
were and if the project is able to produce an adequate return. The systems design is
also reviewed and compared to the performance of the system to see if the information
requirements processes (phases two and three) were performed adequately. In
general, the time, costs and requirements are the three main elements of any IT
project, and those elements should be benchmarked somehow.
This step also reviews all of the system documentation to determine if it is adequate for
the next phase: maintenance. If it is developed properly and according to SDLC best
practices, it will be adequate.
At a minimum, a user acceptance report and a postimplementation report should be
documented during this phase.
COMPUTER ASSINGMENT MBA - II

6


Phase Eight: Systems Maintenance
IT professionals and IT auditors know that 80 percent of the costs and time spent on a
software system, over its life cycle, occur after implementation. It is precisely for this
reason that all of the previously mentioned SDLC documentation should be required.
Obviously, the entity can leverage the 80 percent cost by providing excellent
documentation. That is the place for the largest cost savings over the life of the system.
It is also the argument against cutting corners during development by not documenting
steps and the system.
As changes occur, there should be change authorizations, change implementation and
testing documents created during those changes. Testing during the maintenance
phase should be able to use most of the original test data and test results, significantly
reducing the time and effort necessary to adequately test the changes.
Conclusion
Employing the best practices of SDLC is not just a good idea in the IT industry; it serves
as a control over systems development for IT auditors and provides documentation that
the IT auditor can use to gain assurance over the adequacy and effectiveness of the
entitys SDLC procedures.
IT auditors are able to verify that SDLC best practices are operating effectively by
examining documentation that should have been created during the various phases. Of
course, IT auditors would use other means of verification, such as inquiry and
checklists, but the presence of proper SDLC documentation illustrates the level of
application of the best practices in SDLC. A review of a sample of the documents will
provide evidence that the entity is using SDLC best practices, which provides some
assurance that systems are being developed efficiently and effectively.
Difference between In-House & Out Source
Software development is the process of developing software for particular purpose. It also refers to the
activity of computer programming which the programmer codes and turns into useful application. In
todays ICT era, every business needs software to smoothen the operation. Software can be developed
for different purposes which three most common reasons are to meet the specify client or business
needs, for general purpose or user requirement, and personal/individual organization need.
There is a question in having a software will you or your organization should have a developer team,
outsourcing or to buy from a vendor?
As and IT Manager or a CIO for a company, one should make a clear decision between to have in-house
development or just outsource or buying from someone else. However, before falling into the traps of
making decision for owning the development or to outsourcing, you should have searched and identified
your requirement. Example, if your requirement to cover some kinds of accounting, book keeping and
retail management, restaurant management, HR management, ERP, Core Banking System, and Point of
Sale, then there are plenty of software on the market. You can do Googling or simply buy from vendor.
COMPUTER ASSINGMENT MBA - II

7


But if your need is very specific software such as KPI management, special production or food
processing, company should have a team to handle this task.
Type of Software
As mentioned above, if the software is available on the market such as Accounting System, HR System,
and Point of Saleetc, entity doesnt need to have in-house developers. The best way is to deal with
vendor and negotiate for a better price.
Some organizations need very special software for operation, and that requirement is found no where
either at the vendor or on the market. Thus the best way is to deal with development team. However, this
choice is very costly, headache, time consuming, and last but not least it can be fail at the end.
To avoid the problem, there is suggestion to find the right partner for outsourcing rather than do in-house.
From Management perspective, it is recommended to deal with company rather than individual.
Cost
Cost is the main reason that most companies take into consideration. When outsourcing a project,
software engineers outside of the developed countries are compensated less than their counterparts in
developed countries.
In Cambodia, there is no possible to hire a good programmer in less than 500USD as salary.
Time
There may be few people in the company with the right skills to complete a particular project. In this case
the project is in risk of not meeting its deadlines. The company could hire more skilled people either full
time or on contract. However, this would be expensive and after the project is finished you may not need
the extra manpower. Outsourcing could be a solution. There are many outsourcing companies with many
different specializations. The right company could provide the skills and manpower necessary to meet
any strict deadlines.
Skills
Outsourcing company could provide the client with skills that the client does not have. For example,
maybe the client wants some software coded in a particular technology but the client does not
understand the technology. The outsourcing company could provide these skills to the client. But please
bear in mind that if you are outsourcing a project outside of your company, this could pose problems with
standards and maintenance later on.
Empower Individuals in the Company
Because the offshore company will do the grunt work, this leaves more time for individuals within the
company to concentrate on higher tasks, such as gathering requirements, design and management.
The smart individual will find his/herself leading others, rather than general maintenance and
development work.
Software Development is Core Business
Some companies core business is software development such as Microsoft, Oracle, SAP, Intuit and so
on need to experience internal use of their own software. When their products are about to release on
market, they will sometimes put-in-use within their companies first. If their in-house users say it is
COMPUTER ASSINGMENT MBA - II

8


working fine, then they release on market. But some software development companies dont own the
business model that their software is based on. Its including Core Banking System, HR System etc.
The Need of constant management
Constant management is the number one reason why outsourced projects fail. This job needs to have
good manager and a leader who is in constant communication with offshore vendor. The leader needs to
understand the requirements and make sure that the offshore vendor also understands the requirements.
The client should make sure that standards are being met by viewing code, looking at latest builds,
viewing the bug tracker, and viewing language resource files. A lack of constant management generally
means the project will get out of control.
Increase in Frustration
An increase in frustration in the company could arise for a number of reasons:
1. Time difference: Usually, there is about a half day difference between client and offshore vendor. This
makes communication very difficult. A question could be asked on Monday, will be answered on
Tuesday. A response to the requested on Wednesday will be replied on Thursday. To solve this problem,
there should be schedule weekly meetings. If a difficult problem arises schedule an extra meeting is to
be discussed. Any decent offshore vendor should understand the need for good, timely communication
and be willing to meet on your schedule.
2. Low quality: If the offshore company produces low quality code or architecture, this will definitely
increase frustration within the company. This needs to be solved by having all people who will be re-
sponsible for maintaining the code/architecture involved early on in the project. Code reviews need to be
done frequently. If frequent meetings for code reviewing with customers are not done, then the chance to
receive a product that does not meet requirements is poorly written, not maintainable, and not scalable to
your liking.
3. This isnt what I need!: Generally, customers are not very good at describing exactly what they need.
Sometimes, it is because they do not know who they are. The earlier you can show the developing
system to the customer, the better. Then you will discover that maybe the requirements werent clearly
communicated.
Be warned that the offshore vendor is easily made a scapegoat. Disgruntled employees will jump at the
chance to blame the offshore company for any mistake made. The employee should be reminded that
nobody is perfect. If a mistake is made by the offshore company you could empower the employee to
find out the reason for the mistake, and ask him/her to solve the problem by working with the leader and
the offshore company.
Testing more difficult
Generally, the testing phase of outsourced project is more difficult than an in-house. If you test a piece of
software that was developed offshore in-house and find a problem, this needs to be communicated to the
offshore vendor. This could cause problems as the offshore vendor might not be able to reproduce the
problem. It could be easily fixed if only they could see the machine that it happened on. Or maybe the
problem isnt properly communicated.
Company Morale
Choosing to outsource a project instead of developing in house could affect company morale. Employees
could feel that their jobs are threatened. If jobs are at risk, then the employees should know as soon as
possible to reduce the spread of bad morale. Likewise, if jobs are not threatened, then the employees
should be told of the change, and their jobs are safe, but the employees will be given the chance to do a
higher level of work.
COMPUTER ASSINGMENT MBA - II

9



In House Out Source
Overview Overview
The customer takes on an internal staff member who is
responsible for IT.Staff member is seldom equipped
with proper network management tools due to
extremely high costs.
Maintenance work is performed manually during office
hours.
An external company is paid to spend a certain number of
hours per week/month on support.Any additional support is
billed per hour.
After-hours work is billed at higher rates.
Proper network management tools are seldom deployed at
the clients premises due to prohibitive pricing.
Maintenance work performed manually during office hours.
Pros Pros
Perceived benefit of being able to manage own staff.
Unfortunately, managing IT staff comes with its own set
of challenges which often arent fully appreciated until it
is too late.
The interests of the IT support company are directly
opposed to those of the customer, as the IT support
company benefits from any additional IT support hours
which the customer uses.Staff training, skills redundancy,
etc. is the responsibility of the Service Provider.
Finding and retaining good IT staff is the responsibility of
the Service Provider
Cons Cons
Financial risk lies with the customer. In the event of a
system failure, the in-house technician is responsible
for recovering it.
However, many times this requires deeper skills than
the in-house staff possess and as a result an external
consultant is called in, at hourly rates.
Best-effort by in-house staff.
No guarantee in terms of service levels.
Staff training, skills redundancy, etc. is the responsibility
of the customer.
Finding and retaining IT staff is the responsibility of the
customer.
Maintenance tasks (updates, anti-virus scans, disk
cleanups, etc.) are performed during work hours; this
has a significant impact on productivity.
Financial risk lies solely with the customer.In the event of a
system failure, the customer carries the cost of the
recovery.
Any after-hours work is billed at overtime rates, increasing
the financial risk carried by the customer.
Time-based billing results in highly unpredictable IT
support costs.
Maintenance tasks (updates, anti-virus scans, disk
cleanups, etc.) are performed during work hours; this has
a significant impact on productivity
COMPUTER ASSINGMENT MBA - II

10