Number System in Computer

A set of values used to represent different quantities is known as Number System".

For example, a number system can be used to represent the number of students in a class or number of
viewers watching a certain TV program etc.

The digital computer represents all kinds of data and information in binary numbers. It includes audio,
graphics, video, text and numbers. The total number of digits used in a number system is called its
base or radix. The base is written after the number as subscript such as 51210.

Some important number systems are as follows.

 Decimal number system
 Binary number system
 Octal number system
 Hexadecimal number system

The decimal number system is used in general. However, the computers use binary number system.
The octal and hexadecimal number systems are used in the computer.

A digital system can understand positional number system only where there are a few symbols called
digits and these symbols represent different values depending on the position they occupy in the
number.
A value of each digit in a number can be determined using
 The digit
 The position of the digit in the number
 The base of the number system (where base is defined as the total number of digits available in
the number system).

Number Bases
A number base is a specific collection of numbers on which a number system can be built. Following
are different number bases used.

As a computer programmer or an IT professional, you should understand the following number

systems which are frequently used in computers.

S.N. Number System & Description

1 Binary Number System
Base 2. Digits used: 0, 1
2 Octal Number System
Base 8. Digits used: 0 to 7
3 Decimal Number System
Base 10. Digits used: 0 to 9
4 Hexa Decimal Number System
Base 16. Digits used: 0 to 9, Letters used: A- F
Binary Number System
Characteristics
 Uses two digits, 0 and 1.
 Also called base 2 number system
 Each position in a binary number represents a 0 power of the base (2). Example: 20
 Last position in a binary number represents an x power of the base (2). Example: 2x where x
represents the last position - 1.

Example

Binary Number: 101012

Note: 101012 is normally written as 10101.

Octal Number System

Characteristics
 Uses eight digits, 0,1,2,3,4,5,6,7.
 Also called base 8 number system
 Each position in an octal number represents a 0 power of the base (8). Example: 80
 Last position in an octal number represents an x power of the base (8). Example: 8x where x
represents the last position - 1.

Example

Octal Number − 125708

Note: 125708 is normally written as 12570.

Decimal Number System

The number system that we use in our day-to-day life is the decimal number system. Decimal number
system has base 10 as it uses 10 digits from 0 to 9. In decimal number system, the successive positions
to the left of the decimal point represent units, tens, hundreds, thousands and so on.
Each position represents a specific power of the base (10). For example, the decimal number 1234
consists of the digit 4 in the units position, 3 in the tens position, 2 in the hundreds position, and 1 in
the thousands position, and its value can be written as:
(1×1000) + (2×100) + (3×10) + (4×l)
(1×103) + (2×102) + (3×101) + (4×l00)
1000 + 200 + 30 + 1
1234

Hexadecimal Number System

Characteristics
 Uses 10 digits and 6 letters, 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F.
 Letters represents numbers starting from 10. A = 10, B = 11, C = 12, D = 13, E = 14, F = 15.
 Also called base 16 number system.
 Each position in a hexadecimal number represents a 0 power of the base (16). Example 160.
  Last position in a hexadecimal number represents an x power of the base (16). Example 16x
where x represents the last position - 1.

Example

Hexadecimal Number: 19FDE16

Note − 19FDE16 is normally written as 19FDE.

Number System Conversions (B, O, H, D)

There are many methods or techniques which can be used to convert numbers from one base to
another. We'll demonstrate here the following:

Decimal Octal

Binary
Hexa Decimal

 Decimal to Other Base System

Decimal Number System Octal Number System

Hexa Decimal Number

Binary Number System System

 Step 1 − Divide the decimal number to be converted by the value of the new base.
 Step 2 − Get the remainder from Step 1 as the rightmost digit (least significant digit) of new
base number.
 Step 3 − Divide the quotient of the previous divide by the new base.
 Step 4 − Record the remainder from Step 3 as the next digit (to the left) of the new base
number.
Repeat Steps 3 and 4, getting remainders from right to left, until the quotient becomes zero in Step 3.
The last remainder thus obtained will be the Most Significant Digit (MSD) of the new base number.

(1) Decimal To Binary

(2) Decimal To Octal
(3) Decimal To Hexa Decimal

Example – Decimal To Binary

Decimal Number: 2910

Calculating Binary Equivalent :
Step Operation Result Remainder
Step 1 29 / 2 14 1
Step 2 14 / 2 7 0
Step 3 7/2 3 1
Step 4 3/2 1 1
Step 5 1/2 0 1
As mentioned in Steps 2 and 4, the remainders have to be arranged in the reverse order so that the first
remainder becomes the Least Significant Digit (LSD) and the last remainder becomes the Most
Significant Digit (MSD).
Decimal Number − 2910 = Binary Number − 111012.

Example – Decimal To Octal

Decimal Number: 16810

Calculating Binary Equivalent :
Step Operation Result Remainder
Step 1 168 / 8 21 0
Step 2 21 / 8 2 5
Step 3 2/8 0 2
Decimal Number − 16410 = Octal Number – 2508.

Example – Decimal To Hexa Decimal

Decimal Number: 161610

Calculating Binary Equivalent :
Step Operation Result Remainder
Step 1 1616 / 16 11 0
Step 2 11 / 16 0 11(B)
Decimal Number − 16410 = Hexa Decimal Number – B016.
  Other Base System to Decimal

Decimal Number Octal Number System

System

Binary Number System Hexa Decimal Number

System

Steps
 Step 1 - Determine the column (positional) value of each digit (this depends on the position of
the digit and the base of the number system).
 Step 2 - Multiply the obtained column values (in Step 1) by the digits in the corresponding
columns.
 Step 3 - Sum the products calculated in Step 2. The total is the equivalent value in decimal.

(1) Binary To Decimal

(2) Octal To Decimal
(3) Hexa Decimal To Decimal

Example –Binary To Decimal

Example
Binary Number: 111012
Calculating Decimal Equivalent:

Steps Binary Number Decimal Number

Step 1 111012 ((1 x 24) + (1 x 23) + (1 x 22) +
(0 x 21) + (1 x 20))10
Step 2 111012 (16 + 8 + 4 + 0 + 1)10
Step 3 111012 2910
Binary Number: 111012 = Decimal Number: 2910

Example –Octal To Decimal

Example
Octal Number: 13578
Calculating Decimal Equivalent:

Steps Octal Number Decimal Number

Step 1 13578 ((1 x 83) + (3 x 82) + (5 x 81) +
(7 x 80))10
Step 2 13578 (512 + 192 + 40 + 7)10
Step 3 13578 75110
Octal Number: 13578 = Decimal Number: 75110

Example –Hexa Decimal To Decimal

Example
Hexa Decimal Number: 5A116
Calculating Decimal Equivalent:

Steps Hexa Decimal Decimal Number

Number
Step 1 5A116 ((5 x 162) + (A(10) x 161) + (1
x 160))10
Step 2 5A116 (1280 +160 + 16)10
Step 3 5A116 145610
Hexa Decimal Number: 5A116 = Decimal Number: 145610

 Binary System to Octal, Hexa Decimal

1> Binary To Octal

Steps
 Step 1 - Divide the binary digits into groups of three (starting from the right).

 Step 2 - Convert each group of three binary digits to one octal digit.

Example
Binary Number: 101012
Calculating Octal Equivalent:

Step Binary Number Octal Number

Step 1 101012 010 101
Step 2 101012 28 58
Step 3 101012 258
Binary Number: 101012 = Octal Number: 258

2> Binary To Hexa Decimal

Steps
 Step 1 - Divide the binary digits into groups of four (starting from the right).

 Step 2 - Convert each group of four binary digits to one Hexa Decimal digit.
Example
Binary Number: 101012
Calculating Octal Equivalent:

Step Binary Number HexaDecimal Number

Step 1 101012 0001 0101
Step 2 101012 116 516
Step 3 101012 1516
Binary Number: 101012 = Hexa Decimal Number: 1516

 Octal, Hexa Decimal to Binary System

1> Octal To Binary

Steps
 Step 1 - Convert each octal digit to a 3 digit binary number (the octal digits may be treated as
decimal for this conversion).

 Step 2 - Combine all the resulting binary groups (of 3 digits each) into a single binary number.

Example
Octal Number: 258
Calculating Binary Equivalent:
Step Octal Number Binary Number
Step 1 258 28 58 (210 510)
Step 2 258 0102 1012
Step 3 258 0101012
Octal Number: 258 = Binary Number: 101012

2> Hexa Decimal To Binary

Steps
 Step 1 - Convert each hexadecimal digit to a 4 digit binary number (the hexadecimal digits
may be treated as decimal for this conversion).

 Step 2 - Combine all the resulting binary groups (of 4 digits each) into a single binary number.

Example
Hexadecimal Number: 1516
Calculating Binary Equivalent:
Step HexaDecimal Number Binary Number
Step 1 1516 110 510
Step 2 1516 00012 01012
Step 3 1516 000101012
Hexa Decimal Number: 1516 = Binary Number: 101012

 Octal To Hexa Decimal System AND Hexa Decimal To Octal System

1> Octal To Hexa Decimal

Steps
 Step 1 - Convert each Octal digit to a 3 digit binary number.

 Step 2 - Combine all the resulting binary groups (of 3 digits each) into a single binary number.
 Step 3 - Divide the binary digits into groups of four (starting from the right).

 Step 4 - Convert each group of four binary digits to one Hexa Decimal digit.

Example
Octal Number: 258
Calculating Binary Equivalent:

1> Convert Octal To Binary

Step Octal Number Binary Number
Step 1 258 28 58 (210 510)
Step 2 258 0102 1012
Step 3 258 0101012
2> Convert Binary To Hexa Decimal
Step Binary Number Hexa Decimal Number
Step 1 101012 0001 0101
Step 2 101012 116 516
Step 3 101012 158
Octal Number: 258 = Hexa Decimal Number: 1516

3> Hexa Decimal To Octal

Steps
 Step 1 - Convert each hexadecimal digit to a 4 digit binary number (the hexadecimal digits
may be treated as decimal for this conversion).

 Step 2 - Combine all the resulting binary groups (of 4 digits each) into a single binary number.
 Step 3 - Divide the binary digits into groups of three (starting from the right).

 Step 4 - Convert each group of three binary digits to one octal digit.

Example
Hexadecimal Number: 1516
Calculating Binary Equivalent:

1> Convert Hexa Decimal To Binary

Step HexaDecimal Number Binary Number
Step 1 1516 110 510
Step 2 1516 00012 01012
Step 3 1516 000101012
2>Convert Binary To Octal
Step Binary Number Octal Number
Step 1 101012 010 101
Step 2 101012 28 58
Step 3 101012 258
Hexa Decimal Number: 1516 = Octal Number: 258

Binary system complements

As the binary system has base r = 2. So the two types of complements for the binary system are 2's
complement and 1's complement.

1's complement

The 1's complement of a number is found by changing all 1's to 0's and all 0's to 1's. This is called as
taking complement or 1's complement. Example of 1's Complement is as follows.

2's complement

The 2's complement of binary number is obtained by adding 1 to the Least Significant Bit (LSB) of 1's
complement of the number.

2's complement = 1's complement + 1

Example of 2's Complement is as follows.

Binary arithmetic is essential part of all the digital computers and many other digital systems.

Binary Addition
It is a key for binary subtraction, multiplication, division. There are four rules of binary addition.

In fourth case, a binary addition is creating a sum of (1 + 1 = 10) i.e. 0 is written in the given column
and a carry of 1 over to the next column.

Example − Addition

Binary Subtraction
Subtraction and Borrow, these two words will be used very frequently for the binary subtraction.
There are four rules of binary subtraction.
Example − Subtraction

Binary Multiplication
Binary multiplication is similar to decimal multiplication. It is simpler than decimal multiplication
because only 0s and 1s are involved. There are four rules of binary multiplication.

Example − Multiplication

Binary Division
Binary division is similar to decimal division. It is called as the long division procedure.

Example − Division
What is Information Gathering?
Information gathering helps the individual and the organization to undertake complicated tasks that
would otherwise be extremely hard to accomplish if not out rightly impossible without the benefit of
gathered information. As defined in the dictionary, information gathering is the act of collecting
information from various sources through various means.

In the literal sense, information gathering is a basic human skill necessary for undertaking basic
human activities such as eating, sleeping, working etc. For in order to eat, one must know if the food is
edible or not; and in order to sleep, one must know if the sleeping place is comfortable or not.

As applied in the fields of business and other specialized organizations (scientific, military, academic)
however, information gathering is an advanced skill which requires the training and education of
personnel in the procedures and methods of gathering information from sources that are of higher level
than ordinary sources. In the case of interviewing personalities for example, a researcher usually gets
to interview authorities and proper officials, and thus, he must know the proper ways to address
distinguished personalities of the community and the society in general.

In general practice, information gathering is the collection of data for dealing with the individual’s or
the organization’s current situation. More data means more and better ways of dealing with the current
situation. More data broadens the minds of those who will use the data to solve current organizational
problems. New ideas come more easily if there are lots of facts to be used as bases.

There are two main types of sources in the field of information gathering, namely:

 Existing sources – existing sources are those sources of information that can be found in the
printed, in video, in audio and other materials that are available to the public or upon request to
proper bureaucracy.
 Natural sources – natural sources are first hand sources such as those who have tried products,
services and methods, and expressing their experience and opinions to the researcher.

One-on-One Interviews:
One-on-one interviews are the most common technique for gathering requirements, as well as one of
the primary sources of requirements. To help get the most out of an interview, they should be well
thought out and prepared before sitting with the interviewee. The analyst should identify stakeholders
to be interviewed. These can be users who interact with the current or new system, management,
project financers or anyone else that would be involved in the system. When preparing an interview is
it important to ask open-ended questions, as well as closed-ended questions. Open-ended questions
generally help in obtaining valuable information, based on various individuals and the way the
different way they interact with, or view, the system. These types of questions require the interviewee
to explain or describe their thoughts, and cannot be simply answered with a “yes” or “no”. Asking the
interviewee what they like about the current system or how they use it would be examples of open-
ended questions. These types of questions can provide the consultant to further probe for more detail
with follow up questions, in order to get more details. An example open-ended question would be
“What are some of the problems you face on a daily basis?” Close-ended questions can also be useful,
when the interviewer is looking for a specific answer. They can provide specific answers for the
interviewee to choose from, in formats including true or false or multiple choice. Although close-
ended questions do not provide as much detail as open-ended, they can be useful to cover more topics
in a less amount of time. An example of a close-ended question would be “How many telephone
orders are received per day?” Once the questions have been established, it is a good practice to provide
the questions to the interviewee prior to the interview, in the event that the interviewee needs to
prepare. During the interview, the interviewer should obtain permission from the interviewee that
recorders may be used, to ensure that if details are missed while taking notes can easily be retrieved.
At the end of the interview, the results should be provided to the interviewee, for confirmation of their
responses.

Group Interviews:
Group interviews are similar to one-on-one interview, except there is more than one person being
interviewed. Group interviews work well when the interviewees are at the same level or position. A
group interview also has an advantage when there is a time constraint. More thoughts and discussion
can be generated, as someone in the group may state or suggest an idea that may have been overlooked
by others, which in turn can lead to a discussion or provide more information on a particular issue. The
interviewer can gauge which issues are more generally agreed upon, and which are which issues
differ. A major disadvantage can be scheduling the interview. When more than one person are
involved, it may be difficult, or become time consuming, in establishing date and time that works well
for all parties.

Questionnaires/Surveys:
Questionnaires, or surveys, allow an analyst to collect information from many people in relatively
short amount of time. This is especially helpful when stakeholders are spread out geographically, or
there are dozen to hundreds of respondents whose input will be needed to help establish system
requirements. When using questionnaires, the questions should be focused and organized by a feature
or project objective. Questionnaires should be not be too long, to ensure that users will complete them.
When constructing the questionnaire, general guideline to determine the questions would be to ask
“how, where, when, who, what, and why.” For how: “How will you use this feature?” “How might we
meet this business need?” “How will we know this is complete?” For where: “Where does the process
start?” “Where would the user access this feature?” “Where would the results be visible?” For when:
“When will this feature be used?” “When will the feature fail?” “When will we be ready to start?”
For who: “Who will use this feature?” “Who will deliver the inputs for the feature?” “Who will
deliver the outputs of the feature?” For what: “What do I know about this feature?” “What does this
feature need to do?” “What is the end result?” “What must happen next?”

User Observation:
The direct approaches of interviewing and questionnaires provide valuable user feedback based on the
questions asked of them; however, there are times when direct observation may be better suited in
requirement gathering. To get a better understanding of a user in their in current work environment,
the analyst may observe the user themselves. User observation is helpful in assisting the analyst by
getting a full grasp of how the user interacts with the system, firsthand. When the objective is to
improve a task, the analyst can observe the user and how their surroundings affect their interaction
with the system. Sometimes stakeholders may find it difficult in explaining what exactly what their
tasks consists of and what their requirements may be, observing the user in cases like these will help
provide the requirements. User observation may also be useful in validating data that had been
previously collected. Be it in cases where users provide misleading information, or cannot fully
recollect all of their tasks in how they use the system.

User observation should be planned to ensure that all elements are constant surrounding the
observation. This will assist in uncertainty, and the consultant can focus on the user and assist in
knowing what to look for. The analyst will not be distracted and record, or note, irrelevant issues. The
more useful information gathered, the less time it will take to the analyst to dissect and evaluate
afterwards. Timing of the observation can also prove relevant when planning. For optimal results, the
consultant should schedule three different periods of observation: low, normal, and peak times. This
may prove helpful in because the user may interact with the system differently during different times.
The consultant will take into consideration the differences in times time settings and use it to obtain to
construct better requirements to assist in all three times. When observing the user, there are two
approaches the consultant can take, passive or active. In passive observation, the consultant does not
interact with the user while they are working. They simply observe and take notes. While in active
observation, the consultant will ask the user questions during the session. Observations should always
be done without bias, as in other requirement gathering techniques, the analyst must simply record
what is presented to them, and avoid making comments on whether they believe what is correct or not.
A checklist can provide to be useful, with key points already noted and the consultant verifying events
on their list. For example, they can check if a user uses certain features, the frequency of events,
triggers that cause different uses. Taking detailed notes is helpful in recording unexpected events.
There may be events unknown to the analyst ahead of time, they can be captured by taking notes of the
event and why it occurred. Video recorders may be used, but must always be approved with the user
and their company.

While there are many advantages to use observation, there are some disadvantages associated as well.
As previously mentioned, observations should take place during peak, normal, and low business times.
However, it may still be difficult to capture enough information in one of these sessions. There may be
the need for multiple sessions to verify that facts collected were constant, rather than isolated
incidents. Analysts themselves can sometimes be biased in what they expected to see, and what they
actually observed. Again, the focus is to simply collect the facts, not form any biased opinion when
seeing the working environment. The users sometimes may not themselves provide an accurate
depiction of their every day task and respond differently. Some users may become nervous, and not
perform as they normally would. Other users may try and perform more better or worker harder when
they know they are being observed. Such observations can inhibit the analyst to decipher what the true
requirements actually should be.

Analyzing Existing Documents:

Analyzing existing documents can prove to be a useful technique in requirement gathering, on its own
as well using it to supplement other techniques. Reviewing the current process and documentation can
help the analyst understand the business, or system, and its current situation. Existing documentation
will provide the analyst the titles and names of stakeholders who are involved with the system. This
will help the analyst formulate questions for interviews or questionnaires to ask of stakeholders, in
order to gain additional requirements. If an analyst is uncertain why certain procedures are in place,
this can also help the analyst in asking these questions during interviews. When studying the
requirements, the analysts may find problems that they may distinguish on their own. The analyst may
find there was missing information in old documents. They may also find redundancy, in which steps
are unnecessarily repeated. The consultant may look at old requirement documents and reuse of the
requirements that may still be relevant, while discarding others that may be out of date. The reason
why the current system is designed the way it is, which can suggest why certain features were left out.
Principles and rules for the organization itself can be discovered by analyzing documents. Analyzing
documents can be used as a supplement to information obtained from interviews, questionnaires, and
observations. For example, if some of the interview answers are unclear, organizational documents
may help in making sense of some of the interviewee’s answers. Reviewing existing documents may
also assist in understanding why a user performs certain tasks while observing them. A drawback to
analyzing documents is that documents may be outdated, the analyst must confirm whether the
documents are current or not. Another drawback to reviewing documents is it can be very time
consuming, depending on the organization and the system. A system that interacts with many different
facets of the business will have large amounts of documentation to review.

Software Requirements Analysis (Feasibility Study)

In this phase, the development team visits the user and studies their system. They investigate the need
for development in the given system. By the end of the feasibility study, the team furnishes a
document that holds the different specific recommendations for the candidate system. It also includes
the personnel assignments, costs, project schedule and target dates.

The requirements-gathering process is intensified and focuses specifically on software. To understand

the nature of the program(s) to be built, the System Engineer (developer) must understand the
information area for the software, as well as required function, its behaviour, performance and other
systems it interfaces with.

The crucial purpose of this phase is to find the need and to define the problem that has to be solved.

A feasibility report will do all of this when it is produced.

Feasibility is defined as the practical extent to which a project can be performed successfully. To
evaluate feasibility, a feasibility study is performed, which determines whether the solution
considered to accomplish the requirements is practical and workable in the software. Information
such as resource availability, cost estimation for software development, benefits of the software to the
organization after it is developed and cost to be incurred on its maintenance are considered during
the feasibility study. The objective of the feasibility study is to establish the reasons for developing the
software that is acceptable to users, adaptable to change and conformable to established standards.
Various other objectives of feasibility study are listed below.

 To analyze whether the software will meet organizational requirements

 To determine whether the software can be implemented using the current technology and
within the specified budget and schedule
 To determine whether the software can be integrated with other existing software.

What is a data flow diagram?

A data flow diagram shows the way information flows through a process or system. It includes
data inputs and outputs, data stores, and the various sub processes the data moves through.
 DFDs are built using standardized symbols and notation to describe various entities and their
relationships.

Data flow diagrams visually represent systems and processes that would be hard to describe in
a chunk of text. You can use these diagrams to map out an existing system and make it better
or to plan out a new system for implementation. Visualizing each element makes it easy to
identify inefficiencies and produce the best possible system.

What does Process Specification mean?

A process specification is a method used to document, analyze and explain the decision-making logic
and formulas used to create output data from process input data. Its objective is to flow down and
specify regulatory/engineering requirements and procedures. High-quality, consistent data requires
clear and complete process specifications.

A process specification reduces ambiguity, allowing an individual or organization to obtain a precise

description of executed tasks and accomplishments and validate system design, including the data
dictionary and data flow diagrams.

Input Design
In an information system, input is the raw data that is processed to produce output. During the input
design, the developers must consider the input devices such as PC, MICR, OMR, etc.

Therefore, the quality of system input determines the quality of system output. Well designed input
forms and screens have following properties −

 It should serve specific purpose effectively such as storing, recording, and retrieving the
information.
 It ensures proper completion with accuracy.
 It should be easy to fill and straightforward.
 It should focus on user’s attention, consistency, and simplicity.
 All these objectives are obtained using the knowledge of basic design principles regarding −
o What are the inputs needed for the system?
o How end users respond to different elements of forms and screens.

Objectives for Input Design

The objectives of input design are −

 To design data entry and input procedures

 To reduce input volume
 To design source documents for data capture or devise other data capture methods
 To design input data records, data entry screens, user interface screens, etc.
 To use validation checks and develop effective input controls.

Data Input Methods

It is important to design appropriate data input methods to prevent errors while entering data. These
methods depend on whether the data is entered by customers in forms manually and later entered by
data entry operators, or data is directly entered by users on the PCs.
A system should prevent user from making mistakes by −

 Clear form design by leaving enough space for writing legibly.

 Clear instructions to fill form.
 Clear form design.
 Reducing key strokes.
 Immediate error feedback.

Some of the popular data input methods are −

 Batch input method (Offline data input method)

 Online data input method
 Computer readable forms
 Interactive data input

Input Integrity Controls

Input integrity controls include a number of methods to eliminate common input errors by end-users.
They also include checks on the value of individual fields; both for format and the completeness of all
inputs.

Audit trails for data entry and other system operations are created using transaction logs which gives a
record of all changes introduced in the database to provide security and means of recovery in case of
any failure.

Output Design
The design of output is the most important task of any system. During output design, developers
identify the type of outputs needed, and consider the necessary output controls and prototype report
layouts.

Objectives of Output Design

The objectives of input design are −

 To develop output design that serves the intended purpose and eliminates the production of
unwanted output.
 To develop the output design that meets the end users requirements.
 To deliver the appropriate quantity of output.
 To form the output in appropriate format and direct it to the right person.
 To make the output available on time for making good decisions.

Let us now go through various types of outputs −

External Outputs

Manufacturers create and design external outputs for printers. External outputs enable the system to
leave the trigger actions on the part of their recipients or confirm actions to their recipients.

Some of the external outputs are designed as turnaround outputs, which are implemented as a form
and re-enter the system as an input.
Internal outputs

Internal outputs are present inside the system, and used by end-users and managers. They support the
management in decision making and reporting.

There are three types of reports produced by management information −

 Detailed Reports − They contain present information which has almost no filtering or
restriction generated to assist management planning and control.
 Summary Reports − They contain trends and potential problems which are categorized and
summarized that are generated for managers who do not want details.
 Exception Reports − They contain exceptions, filtered data to some condition or standard
before presenting it to the manager, as information.

Output Integrity Controls

Output integrity controls include routing codes to identify the receiving system, and verification
messages to confirm successful receipt of messages that are handled by network protocol.

Printed or screen-format reports should include a date/time for report printing and the data. Multipage
reports contain report title or description, and pagination. Pre-printed forms usually include a version
number and effective date.

SDLC (Software Development Life Cycle)

What is SDLC?

The Software Development Lifecycle is a systematic process for building software that ensures the
quality and correctness of the software built. SDLC process aims to produce high-quality software
which meets customer expectations. The software development should be complete in the pre-defined
time frame and cost.

SDLC consists of a detailed plan which explains how to plan, build, and maintain specific software.
Every phase of the SDLC lifecycle has its own process and deliverables that feed into the next phase.

SDLC Phases
The entire SDLC process divided into the following stages:

 Phase 1: Requirement collection and analysis

 Phase 2: Feasibility study:
 Phase 3: Design:
 Phase 4: Coding:
 Phase 5: Testing:
 Phase 6: Installation/Deployment:
 Phase 7: Maintenance:
Phase 1: Requirement collection and analysis:

The requirement is the first stage in the SDLC process. It is conducted by the senior team members
with inputs from all the stakeholders and domain experts in the industry. Planning for the quality
assurance requirements and reorganization of the risks involved is also done at this stage.

This stage gives a clearer picture of the scope of the entire project and the anticipated issues,
opportunities, and directives which triggered the project.

Requirements Gathering stage need teams to get detailed and precise requirements. This helps
companies to finalize the necessary timeline to finish the work of that system.

Phase 2: Feasibility study:

Once the requirement analysis phase is completed the next step is to define and document software
needs. This process conducted with the help of 'Software Requirement Specification' document also
known as 'SRS' document. It includes everything which should be designed and developed during the
project life cycle.

There are mainly five types of feasibilities checks:

 Economic: Can we complete the project within the budget or not?

 Legal: Can we handle this project as cyber law and other regulatory framework/compliances?
 Operation feasibility: Can we create an operation which is expected by the client?
 Technical: Need to check whether the current computer system can support the software
 Schedule: Decide that the project can be completed within the given schedule or not.

Phase 3: Design:

In this third phase, the system and software design documents are prepared as per the requirement
specification document. This helps define overall system architecture.

This design phase serves as input for the next phase of the model.

There are two kinds of design documents developed in this phase:

High-Level Design (HLD)

 Brief description and name of each module

 An outline about the functionality of every module
 Interface relationship and dependencies between modules
 Database tables identified along with their key elements
 Complete architecture diagrams along with technology details

Low-Level Design (LLD)

 Functional logic of the modules

 Database tables, which include type and size
 Complete detail of the interface
 Addresses all types of dependency issues
 Listing of error messages
 Complete input and outputs for every module
Phase 4: Coding:

Once the system design phase is over, the next phase is coding. In this phase, developers start build the
entire system by writing code using the chosen programming language. In the coding phase, tasks are
divided into units or modules and assigned to the various developers. It is the longest phase of the
Software Development Life Cycle process.

In this phase, Developer needs to follow certain predefined coding guidelines. They also need to use
programming tools like compiler, interpreters, debugger to generate and implement the code.

Phase 5: Testing:

Once the software is complete, and it is deployed in the testing environment. The testing team starts
testing the functionality of the entire system. This is done to verify that the entire application works
according to the customer requirement.

During this phase, QA and testing team may find some bugs/defects which they communicate to
developers. The development team fixes the bug and send back to QA for a re-test. This process
continues until the software is bug-free, stable, and working according to the business needs of that
system.

Phase 6: Installation/Deployment:

Once the software testing phase is over and no bugs or errors left in the system then the final
deployment process starts. Based on the feedback given by the project manager, the final software is
released and checked for deployment issues if any.

Phase 7: Maintenance:

Once the system is deployed, and customers start using the developed system, following 3 activities
occur

 Bug fixing - bugs are reported because of some scenarios which are not tested at all
 Upgrade - Upgrading the application to the newer versions of the Software
 Enhancement - Adding some new features into the existing software

The main focus of this SDLC phase is to ensure that needs continue to be met and that the system
continues to perform as per the specification mentioned in the first phase.

Planning and Managing The Project

In this Module, we look at tracking project progress project personnel and organization effort and
schedule estimation risk management using process modeling with project planning.

TRACKING PROJECT PROGRESS

Project tracking is essential to monitor project progress and identify any project slippage or time delay.
Treat effective time tracking as an early warning system. Effective project tracking allows the project
manager to see emerging problems and deal with them before they become big problems or impact the
project schedule. Given the high project failure rate it is important to ensure that a method exists to
relate the project plan –schedule, tasks and named resources - to time tracking of that project schedule
and its tasks.

3. EFFECTIVE PROJECT TRACKING <ul><li>Clear project tasks with a named resource for
ensuring </li></ul><ul><li>its completion to schedule </li></ul><ul><li>Commitment of named
resource to complete task </li></ul><ul><li>according to schedule </li></ul><ul><li>Regular project
team meetings to discuss and update </li></ul><ul><li>on progress and identify any dependencies
and </li></ul><ul><li>potential risks </li></ul><ul><li>Regular verbal updates of progress with all
named </li></ul><ul><li>resources and identification of any dependencies and
</li></ul><ul><li>risks, especially competing project tasks or worse </li></ul><ul><li>external
factors such as competing projects. These are </li></ul><ul><li>additional to project team meetings
and designed to </li></ul><ul><li>ensure that the project manager is very closely in touch
</li></ul><ul><li>with project progress </li></ul>

4. TRACKING PROJECT PROGRESS <ul><li>Accurate and regular project reporting of progress

and </li></ul><ul><li>% complete of tasks based on team and individual </li></ul><ul><li>updates
</li></ul>

5. RECORDING TIME TRACKING <ul><li>Projects involving more than a few people quickly
</li></ul><ul><li>develop a long list of tasks and dependencies and these </li></ul><ul><li>must be
held in some dedicated software as opposed to </li></ul><ul><li>some manual paper-based method
or a spreadsheet. </li></ul><ul><li>This is because it becomes very complex very quickly to
</li></ul><ul><li>keep a project plan up to date. </li></ul><ul><li>Project time tracking is primarily
about recording the </li></ul><ul><li>time taken by individuals to complete their tasks.
</li></ul><ul><li>Ideally timesheets for recording time are linked into the </li></ul><ul><li>same
software that records the project tasks so that </li></ul><ul><li>updating the timesheet automatically
updates the % </li></ul><ul><li>complete of the assigned tasks. If not, then the project
</li></ul><ul><li>manager must update the project plan with project </li></ul><ul><li>progress.
</li></ul>

6. MANAGING TIME DELAY Every time delay matters but not every time delay requires corrective
action, a simple rule of thumb is: <ul><li>One time delay to an important task triggers an offer of help
and if refused the project manager maintains a watching brief and special attention on that task's
completion </li></ul>2. A second time delay to the same task triggers immediate project manager
action help to solve the issue and to mitigate any further risk of a time delay that impacts the project
schedule

7. MANAGING TIME DELAY 3. A third time delay to an important task is significant enough to
consider re-planning and the project manager should convene a project team meeting of the experts
and key stakeholders to consider the options

8. PROJECT MONITORING - All of these project tracking and time tracking activities will ensure
that the project manager is in touch with progress and able to react to deviations from the project plan
very quickly. - Reacting to a time delay is critical to a successful project and effective project
monitoring is an important part of project risk management.

9. WAYS TO MANAGE PROJECTS ON TIME AND ON BUDGET Here are seven suggested ways
to manage a project on time and on budget: 1. Clearly Defined Project Scope 2. Properly Identified
Resources Requirements 3. Sustained Balance of ‘Process’ and ‘People’ Factors 4. Utility of Tools
and Techniques 5. Keeping Responsible Team Members 6. Applying Constant Project Review and
Evaluation, and Immediately Address all Setbacks 7. Regular Communication with the Relevant
Project Players
10. A FINAL PROJECT INSIGHT - During the post-implementation review, the project is evaluated
for client satisfaction, timing and resource effectiveness and individual performance. For a project
well done, that is, on time and on budget, it is a fulfilling moment for the team to celebrate. -
Managers who use these suggestions are most likely to succeed in their projects. And perhaps even
deliver projects ahead of time and under-budget.

11. WHAT MAKES A SUCCESSFUL PROJECT MANAGER? - Good project manager is essential
to a successful project but being a successful project manager is more than the result of project
management training; it takes ability. - Asking the question -- what makes a successful project
manager?

12. GOOD PROJECT MANAGER SKILLS Good project manager skills will include: 1.
Understanding and possibly formal training in at least one structured project management (waterfall)
methodology such as PMI or PRINCE2 and an iterative method such as Agile 2. Effective leadership
skills, primarily the ability to get things done through other people 3. General soft-skills such as
communication skills, problem-solving skills 4. General knowledge on related topics such as software
development lifecycle, quality management systems, ITIL service management and the like

13. KNOWING-DOING GAP - The knowing-doing gap is like the keen tennis (or chess or project
management...) amateur knowing what to do and how to do it but they cannot do it themselves or at
least not to the standard that the professionals or world champions do. This knowing-doing gap is what
really differentiates between those who can and those who think they can.

14. PROJECT REPORTING ON A PROJECT STATUS CHECKLIST - Project status reporting is a

key communication tool for the project. Use a project report checklist to ensure that content is concise
and complete for intended audience. - A project status report should be based on a set report format,
preferably just one, which is then used for the content targeted at the various stakeholders. - The
project should have already identified the various stakeholder groups, the frequency and type of
project reporting. Importantly, if more than one report format is used the key project messages should
be consistent.

15. PROJECT STATUS REPORT - STAKEHOLDER NEEDS Project reports will be produced for
project tracking and project monitoring but it must address the needs of the stakeholders receiving the
project report. Those needs typically include: 1. Current, accurate information on project progress and
RAG (Red, Amber, Green) Status* <ul><li>RAG Status is a simple way to indicate the project status
using a traffic </li></ul><ul><li>light metaphor: </li></ul><ul><li>Red = project is either very
delayed or significantly over budget or </li></ul><ul><li> both </li></ul><ul><li>Amber = project is
delayed or over budget or both </li></ul><ul><li>Green = project is on track to deliver as scheduled
and within budget </li></ul><ul><li> tolerances [such as +/- 10%] </li></ul>

16. PROJECT STATUS REPORT - STAKEHOLDER NEEDS 2. Barriers to successful project

delivery and what the project team is doing to remove barriers 3. Understanding of business impact
and change 4. What actions stakeholders need to take, if any

17. PROJECT STATUS REPORT CHECKLIST The project status report must focus on being
current, accurate, concise, complete and it must address one or more of the stakeholders needs. The
checklist of key content should include: <ul><li>Current RAG status </li></ul><ul><li>Status of
outstanding actions from previous </li></ul><ul><li>reports/meetings </li></ul><ul><li>Project
progress for key project tasks, especially those </li></ul><ul><li>with significant business impact or
involving a significant </li></ul><ul><li>number of project team members </li></ul><ul><li>Key
third party tasks, especially for vendors or contract </li></ul><ul><li>resource </li></ul>
18. PROJECT STATUS REPORT CHECKLIST <ul><li>Key dependencies with related projects or
programme </li></ul><ul><li>activities </li></ul><ul><li>Status of resources and expectations for
resource </li></ul><ul><li>management </li></ul><ul><li>Key risks regarding people, process and
technology and </li></ul><ul><li>project risk mitigation plan </li></ul><ul><li>Management of
current issues and their status </li></ul><ul><li>Current progress regarding project deliverables and
</li></ul><ul><li>documentation </li></ul><ul><li>Status of inter-related or delegated
accountabilities </li></ul><ul><li>such as business change management </li></ul><ul><li>Clear
identification of stakeholder actions needed, if any </li></ul><ul><li>Actions from project reviews, if
any </li></ul>

19. PROJECT REPORTING <ul><li>Project reporting done well will ensure that stakeholders feel
well informed and that the project communication is working. </li></ul><ul><li>Use the checklist in
conjunction with a strong emphasis on being concise. </li></ul><ul><li>Project reports that contain a
lot of words but say very little of substance will soon be devalued by being ignored.
</li></ul><ul><li>Brevity is critical to ensuring that stakeholders will take the time to read it and
absorb the content. </li></ul><ul><li>Consequently do not try to report on everything - only those
items of real significance to people not interested in the project level of detail. </li></ul>

20. PROJECT EVALUATION AND SELECTING PROJECT METRICS <ul><li>Project

management metrics are important to the extent that they are used for project process improvement.
The intent of project metrics is clear performance improvement. </li></ul><ul><li>The reasons for
doing a project should be results-oriented and benefit driven and consequently there should be targeted
benefit measures to demonstrate success. </li></ul><ul><li>Ideally, benefits management will start
the project and continue when the project has ended. Project metrics are in-process or project
execution measures that are collected, analyzed and used to drive project process improvement.
</li></ul>

21. REASONS FOR PROJECT METRICS Project metrics require time and effort and so that work is
done for usually one of these reasons: <ul><li>To provide clear and tangible project status
information about project schedule and cost </li></ul><ul><li>To identify areas for project process
improvement </li></ul><ul><li>To demonstrate the results of process improvement efforts
</li></ul><ul><li>To collect a database of project metrics to analyze trend information or provide
historic comparators and perhaps used for parametric estimates </li></ul>

22. REASONS FOR PROJECT METRICS Key project management metrics include:
<ul><li>Schedule - delivery date and slippage in days from </li></ul><ul><li>original delivery date
</li></ul><ul><li>2. Cost - actual budget versus original budget key project
</li></ul><ul><li>management metrics include: </li></ul><ul><li>3. Resource - effort, how much
time people have used on </li></ul><ul><li>the project </li></ul><ul><li>4. Scope - changes to
project as measured through </li></ul><ul><li>number and type of controlled changes made
</li></ul>

23. REASONS FOR PROJECT METRICS 5. Quality - quality defects and documentation 6. Software
- a specialised subject with many potential measures such as lines of code, code complexity and
function point 7. Defects - number and type of problems or issues recorded for the technology project
during its test stage and warranty period or a defined time period

24. REASONS FOR PROJECT METRICS 5. Quality - quality defects and documentation 6. Software
- a specialised subject with many potential measures such as lines of code, code complexity and
function point 7. Defects - number and type of problems or issues recorded for the technology project
during its test stage and warranty period or a defined time period
25. PROJECT EVALUATION <ul><li>Project evaluation is a function of meeting original objectives
for expected benefits and also the in-process project execution. Benefits should drive project initiation
and so the key focus for project metrics should be to improve project processes. That is the real value
of project metrics - the positive changes that they can drive, leading to more successful projects.
</li></ul><ul><li>Project closure is the final phase of any project. It is just as important as the other
project phases of initiating, planning and monitoring. However, not many companies pay sufficient
attention to this phase and others just do not bother with it at all. </li></ul>

26. PROJECT EVALUATION A project can be terminated two (2) ways. Firstly, there is natural
closure. This occurs when the project requirements have all been met. Secondly, there is unnatural
closure. This occurs when some assumptions prove to be false, performance is inadequate or the
project's requirements have changed and are no longer valid. The most frequent causes of unnatural
closure are time and money.

27. BENEFITS OF PROJECT CLOSURE Project closure must be recognized and documented. For
the best possible project closure, the project team must perform the following activities:
<ul><li>Closeout begins on the first day of the planning phase; </li></ul><ul><li>Review
outstanding work packages or activities; </li></ul><ul><li>Confirm that resources are still available
to perform any remaining work; </li></ul><ul><li>Review change control log to identify any
outstanding change requests; </li></ul><ul><li>Check with sales and marketing to identify any
outstanding items with the customers; and </li></ul><ul><li>Prepare all project documentation for a
post-project review. </li></ul>

28. BENEFITS OF PROJECT CLOSURE There are also certain activities which the (overall)
company must perform. They are: <ul><li>Identify and release available resources;
</li></ul><ul><li>Notify the transition team of the upcoming turnover; </li></ul><ul><li>Prepare
any necessary performance evaluations; and </li></ul><ul><li>Notify the accounting section and
conduct internal </li></ul><ul><li>review processes. </li></ul>

29. RISK MONITORING AND CONTROL - Risk control is working the risk management plan
while, at the same time, ensuring the plan is still valid. The project team must continuously make sure
that assumptions are still valid. - They must also review the risks and probabilities for accuracy. - Risk
monitoring control is performed at the concept phase of the project and ends at the close-our phase. It
should be included in the regular communication process of the project. - Risk control is also
performed prior and the during the risk event. It is performed whenever there are changes to the
project scope and on a regularly scheduled basis.

30. RISK MONITORING AND CONTROL - Risk control is working the risk management plan
while, at the same time, ensuring the plan is still valid. The project team must continuously make sure
that assumptions are still valid. - They must also review the risks and probabilities for accuracy. - Risk
monitoring control is performed at the concept phase of the project and ends at the close-our phase. It
should be included in the regular communication process of the project. - Risk control is also
performed prior and the during the risk event. It is performed whenever there are changes to the
project scope and on a regularly scheduled basis.