Assignment:

application
portfolio
management

Course no: 106

Subject: computer
applications.
The business school,
university of Jammu
Submitted to:
Submitted by: Ms.
rachna
pankaj dogra
Gupta
M.b.a(1stsem.)
Roll no. 21

Introduction:
Stages of the system development life cycle are some times referred to as system study.
The system analyst gives a system development project meaning and direction. A
candidate system is approached after the analyst has a thorough understanding of user
needs and problems, has developed a viable solution to these problems and then
communicates the solution through the installation of a candidate system. Candidate
system often cut across the boundaries of the users in the organization. To make sure that
all users’ needs are met a project team that represents each user works with the analyst to
carry out a system development project.
To understand system development, we need to
recognize that a candidate system has a lifecycle, just like a new system or a new product.
System analysis and design are keyed to system lifecycle. The analyst must progress from
one stage to another, answering key questions and achieving results in each stage.
The format of a system development methodology
and standards will vary from organization to organization and indeed within the
organization the procedures must be flexible enough to allow for a certain amount of
adaptation to cater for the characteristics of individual systems. The development of a
business system takes place in a series of stages that forms the system development life
cycle. Though every organization must follow the system development process that suits
its own needs, all organizations will follow stages outlined here. These stages are as
follows:

1. preliminary investigation and feasibility study

2. specification of requirements
3. system design
4. programming
5. system testing
6. implementation
7. system review
Recognition of need:
One must know what the problem is before it can be solved. The basis of a candidate
system is recognition of a need or improving an information system or a procedure.
Example: a supervisor may want to investigate the system flow in purchasing, or a bank
president has been getting complaints about the long lines in the drive-in. this need leads
to a preliminary survey or an initial investigation to determine whether an alternative
system can solve the problem. It entails looking into the duplication of effort, bottlenecks,
inefficient existing procedures, or whether parts of the existing system would be
candidates for computerization.

Most organizations appoint a project team to do the system development. The team is
likely to be composed of 5 to 10 people, including system analysts, programmers and
users. A project leader is appointed to guide the project. Before a system development
project begins, there must be a significant expression of need. The expression of need
comes from work in four areas:

1) Perceiving a problem.
2) Defining the problem.
3) Relating the problem to the domain of the computer.
4) Formalizing the need.

1) Preliminary investigation and feasibility study

This is the first phase and consists of a brief survey of areas involved and will result in
taking the project into next phase, post phoning the development for a period or
recommending that no further action be taken. Sometimes it is subdivided into a
preliminary investigation followed by a more detailed feasibility study.

Request clarification:

Many requests from employees and users in organizations are not clearly state. Therefore,
before any system investigation can be considered the project request must be examined
clearly what the originator wants. A simple telephone call may suffice if the requester has
a clear idea but does not know how to state it.
The objectives of this phase are:
 1) To determine the feasibility of computerization of a particular system or area of
operation.
2) To define Clearly the objectives, scope and limitations of the project
3) To establish a good working relationship between user department and data
processing department
4) To identify the likely benefits which should accrue from the introduction of te
system.

Feasibility study:

Many feasibility studies are disillusioning for both users and analysts. First, the study
often presupposes that when the feasibility document is being prepared, the analyst is in a
position to evaluate solutions. Second, most studies tend to overlook the confusion inherit
insystem development---the constraints and the assumed attitudes .four tests of feasibility
are studied. All are equally important.

1) Technical feasibility: it involves determining whether or not a system can actually

be constructed to solve the problem at hand.
2) Operational feasibility: this test of feasibility asks if the system will work when
developed and installed.
3) Political feasibility: it is perhaps the most powerful type. This involves the extent
of managerial support for changes to the present system
4) Economic feasibility: it involves estimating benefits and costs.

System study report

The out put from this report is a formal repot called a feasibility report. This report may
contain:

1) The objectives for the system

2) An introduction which puts the report in perspective and perhaps quotes the terms of
reference.
3) Interfaces with other systems and the implications of these interfaces
4) a cost benefit projection.

Request approval

Not all the requested projects are desirable or feasible. In fact some organizations receive
so many project requests that only a few of them can be pursued. When this happens
management decides what projects are most important and schedules them. After a
project is approved, its cost, priority, completion time and personal requirements are
estimated and used to determine and used to deter mine where to add it on any existing
project lit.

Handling of infeasible projects

Not all projects submitted for evaluation and review are judged acceptable. Requests
passing feasible tests are not pursued further, unless the originators rework them and
resubmit the as new proposals. Some times preliminary investigations produce enough
new information to suggest that improvements in management supervision are really the
solution to reported problem, not the development of information system.

2) specification of requirements/analysis

Analysis is a detailed study of the various operations performed by a system and their
relationship within and outside the system. A key question is:
What must be done to solve the problem? One aspect is defining the boundaries of the
system and determining whether or not a candidate system should consider other related
systems. During analysis data are collected on the available files, decision points, and
transactions handled by the present system. Data flow diagrams, interviews, online
observations, and questionnaires are examples. The interview is a commonly used tool in
analysis. Analysists working with employees and managers must study the business
process to answer these questions:

1) What is being done?

2) How is being done?
3) How frequently does it occur?
4) Does a problem exist?
5) If a problem exists, what is the underlying cause?

3) system design
The most creative challenging phase of the system life cycle is system design. The
term design describes a final system and the process by which system is developed. It
refers to the technical specifications that will be applied in implementing the
candidate system. It also includes the construction of program and program testing.
The first step is to determine how the output is
to be produced and in what format. Second, input data and master files have to be
designed to meet the requirements of the proposed output. Finally details related to
justification of the system and an estimation of the impact of the candidate system on
the user and the organization are documented and evaluated by management as a step
towards implementation.

The finished design of a solution should contain:

• Alternative solutions to the problem - in what different ways could the problem be
solved?
• Data structure (e.g. field names, data types and lengths, file naming, folder
structure schemes, color coding, style guide requirements).
• How the data is to be acquired (what procedures and equipment will be needed?)
• Data input procedures and equipment (e.g. keyboard? barcode reader? OCR?)
• Interfaces (e.g. what will a data entry screen look like? Will people need to leave
the main screen to access functions? How will menus be organized into
commands and submenus? What shortcut keys will be used?
• Control procedures - What validation rules will be used on what fields to check
for data reasonableness, existence or format?) What will different error messages
say? How can output be checked for accuracy
Equipment sources - will equipment be tailor-made or 'off the shelf'? In either
case, hardware and software specifications must be given. It should consider:
o What features are required
o What hardware requirements the software has (e.g. memory, peripheral
devices, storage volumes)
o What software requirements the hardware has (e.g. operating system)
o The cost
o How long the equipment will take to develop
o What training and documentation will be required
o Whether the equipment can be adapted to cater for future needs
o Whether the system can be maintained or repaired
4) Programming
the document gives the programmer a clear description of the system, its purpose and
objectives ,the program involved and the interrelationship between them program
specification may consist of a low level description of what the program should do,
flow charts, decision tables and structure diagrams. Software developers may modify
the existing programs or install purchase commercial software or they may write new
custom designed programs. Typically in larger organizations computer programmers
or combined analysts programmers are part of the permanent professional staff. In
small firms where permanent programmers have been hired, documentation is
essential to test the program and carry on maintenance once the application has been
installed.

4) system testing

(1) Testing an information system involves checking that procedures, equipment, and
staff process data as expected. Each component may be tested [component testing] and
then the whole system tested [integration testing].
(2) Test data should be developed to ensure the procedures and formulas of a solution
operate and process data as expected. This test is normally performed during [informal
testing] and immediately after the development of the solution [formal testing]. When
using a programming language it is called debugging. Once debugged, someone not
involved in the program development tests it.

Testing can include:

• Informal testing - is carried out as each new feature of a system is incorporated to

check it is working properly.
• Formal testing - is done when the solution is finished, and needs to be tested as a
whole rather than as a set of parts.
• Component testing: does each component in the system work properly by itself, in
isolation?
• Integration testing: when components are integrated do they still work properly
and interact properly, or are they incompatible (due to hardware, software or data
inconsistencies)?
 • Reliability - does it handle expected and exceptional situations well? e.g. can it
handle the expected 10,000 transactions per hour?
• Black box testing does not care how the system works - it just looks at the input
and checks to see that the expected output comes out the other end. .
• White box testing checks the processes within a component to make sure each
small subcomponent (hardware or software) is producing the correct output.
5) implementation

The implementation phase is less creative than system design it is primarily concerned
with user training, site preparation and file conversion. When the candidate system is
linked to terminals or remote sites, the telecommunication network and tests of the
network along with the system are also included under implementation. During the final
testing, user acceptance is tested, followed by user training. Depending on the nature of
the system, extensive user training may be required.

Technical conversion activities

Depending on the size of the organization that will be involved in using the application
and the risk associated with its use, system developers may choose only to test the
operation in one area of the firm or with just one or two persons.

People oriented activties

Since work tasks are often changed when a new system is installed. User orientation,
training and support are very important part of system implementation. it is not usual to
find a full time system training department in large organizations, since systems are
continuously being installed somewhere.

7) System review
This is the last phase of the development process and is also known as post audit. It is
usually carried by a group consisting of a representative from the user department,
internal audit and data processing. Its basic purpose is to see if the system has met the
objectives set for it.
Two major questions are asked:

1) is the system itself proper?

2) Was the system developed properly?

To decide if the system is working properly, the user must consult if system is providing
the information they need in the correct form. Deficiencies in the system lead to another
lifecycle.