Unit-3

System Development Cycle

Monita Wahengbam
Scientist-’C’
NIELIT Senapati Extension Centre

NIELIT Imphal Senapati Extension Centre 1

Basic Concept of SDLC – System Development
Life Cycle
• A successful Organizations use a standard set of steps, called a systems development
methodology, to develop and support their information systems. Like many processes, the
development of information systems often follows a life cycle.
• For example, a commercial product, such as a
• Nike sneaker or
• a Honda car,
• follows a life cycle:
• It is created,
• tested, and
• introduced to the market.
• Its sales increase,
• peak, and
• decline.
• Finally, the product is removed from the market and
• is replaced by something else.
NIELIT Imphal Senapati Extension Centre 2
• The systems development life cycle (SDLC) is a common methodology for systems
development in many organizations.
• It marks the phases or steps of information systems development:
• Someone has an idea for an information system and what it should do.
• The organization that will use the system decides to devote the necessary resources to
acquiring it.
• A careful study is done of how the organization currently handles the work the system will
support.
• Professionals develop a strategy for designing the new system,
• which is then either built or purchased.
• Once complete, the system is installed in the organization, and
• after proper training, the users begin to incorporate the new system into their daily work.
• Every organization uses a slightly different life-cycle model to model these steps,
with anywhere from three to almost twenty identifiable phases.
NIELIT Imphal Senapati Extension Centre 3
• A successful System Development Life Cycle (SDLC) should result in an astounding
system that meets client desires, achieves expectations within time and cost
assessments, and works viably and productively in the current and planned
Information Technology framework.
• System Development Life Cycle (SDLC) is an applied model which incorporates
strategies and methods for creating or modifying systems throughout their life cycles.
• SDLC is utilized by examiners to build up a data system. SDLC incorporates the
accompanying exercises −
• requirements
• design
• implementation
• testing
• deployment
• operations
• maintenance NIELIT Imphal Senapati Extension Centre 4
Basic Four phases of SDLC
• The system development life cycle structure gives a grouping of exercises to
system designers and engineers to take after. It comprises of an arrangement of
steps or stages in which each period of the SDLC utilizes the aftereffects of the
past one.
• The SDLC holds fast to critical stages that are basic for engineers, for example,
planning, analysis, design, and implementation—and are clarified in the area
beneath. This incorporates assessment of the presently utilized system, data
gathering, feasibility studies, and demand endorsement. Various SDLC models
have been made, including waterfall, fountain, spiral, build and fix, rapid
prototyping, incremental, synchronize, and stabilize. The oldest of these, and the
best known, is the waterfall model, a succession of stages in which the yield of
each stage turns into the contribution for the next.

NIELIT Imphal Senapati Extension Centre 5

• These stages can be described and partitioned up in various ways,
including the following:
• planning and selection,
• analysis,
• design, and
• implementation and operation

NIELIT Imphal Senapati Extension Centre 6

Feasibility Study or Planning
• Characterize the issue and extent of existing system.
• Diagram the new system and decide its goals.
• Affirm venture feasibility and deliver the task Schedule.
• Amid this stage, dangers, imperatives, combination and security of
system are likewise considered.
• A feasibility report for the whole venture is made toward the finish of
this stage.

NIELIT Imphal Senapati Extension Centre 7

Analysis and Specification
• Assemble, examine, and approve the data.
• Characterize the prerequisites and models for new system.
• Assess the options and organize the prerequisites.
• Analyze the data needs of end-client and upgrades the system
objective.
• A Software Requirement Specification (SRS) archive, which
determines the product, equipment, useful, and organize
prerequisites of the system is set up toward the finish of this stage.

NIELIT Imphal Senapati Extension Centre 8

System Design
• Incorporates the design of utilization, organize, databases, UIs, and system
interfaces.
• Change the SRS report into coherent structure, which contains definite and
finish set of specifications that can be executed in a programming dialect.
• Make a possibility, preparing, maintenance, and activity design.
• Survey the proposed design. Guarantee that the last design must meet the
prerequisites expressed in SRS record.
• At long last, set up a design record which will be utilized amid next stages.

NIELIT Imphal Senapati Extension Centre 9

Implementation
• Execute the design into source code through coding.
• Join every one of the modules together into preparing condition that
recognizes mistakes and imperfections.
• A test report which contains mistakes is set up through test arrange
for that incorporates test related undertakings, for example,
experiment age, testing criteria, and asset allotment for testing.
• Incorporate the data system into its condition and introduce the new
system.

NIELIT Imphal Senapati Extension Centre 10

Maintenance/Support
• Incorporate every one of the exercises, for example, telephone
support or physical on location support for clients that is required
once the system is introducing.
• Execute the progressions that product may experience over some
undefined time frame, or actualize any new necessities after the
product is sent at the client area.
• It additionally incorporates handling the leftover blunders and resolve
any issues that may exist in the system even after the testing stage.
• Maintenance and support might be required for a more extended
time for vast systems and for a brief span for littler systems.
NIELIT Imphal Senapati Extension Centre 11
NIELIT Imphal Senapati Extension Centre 12
• Although any life cycle appears at first glance to be a sequentially
ordered set of phases, it actually is not. The specific steps and their
sequence are meant to be adapted as required for a project. For
example,
• in any given SDLC phase, the project can return to an earlier phase, if necessary.
• Similarly, if a commercial product does not perform well just after its
introduction, it may be temporarily removed from the market and improved
before being reintroduced.
• In the systems development life cycle, it is also possible to complete some
activities in one phase in parallel with some activities of another phase.
• Sometimes the life cycle is iterative; that is, phases are repeated as required
until an acceptable system is found.

NIELIT Imphal Senapati Extension Centre 13

• Some systems analysts consider
the life cycle to be a spiral, in which
we constantly cycle through the
phases at different levels of detail,
as illustrated in Figure.
• The circular nature of the life-cycle
diagram in Figure illustrates how
the end of the useful life of one
system leads to the beginning of
another project that will replace
the existing system altogether.
However conceived, the systems
development life cycle used in an
organization is an orderly set of
activities conducted and planned
for each development project. The
skills required of a systems analyst
apply to all lifecycle models
NIELIT Imphal Senapati Extension Centre 14
Various phases of development - Analysis, Design,
Development, Implementation, Maintenance
• Phase 1 -Systems Planning and Selection :
• The first phase of the SDLC, in which an organization’s total
information system needs are analyzed and arranged, and in which a
potential information systems project is identified and an argument
for continuing or not continuing with the project is presented
The first phase in the SDLC, systems planning and selection, has two
primary activities.
• First, someone identifies the need for a new or enhanced system.
• Information needs of the organization are examined, and projects to
meet these needs are identified.
NIELIT Imphal Senapati Extension Centre 15
• The organization’s information system needs may result from:
• Requests to deal with problems in current procedures
• The desire to perform additional tasks
• The realization that information technology could be used to
capitalize on an existing opportunity

NIELIT Imphal Senapati Extension Centre 16

Task in the systems planning and selection
phase
• The systems analyst prioritizes and translates the needs into a written plan for
the information systems (IS) department, including a schedule for developing
new major systems. Requests for new systems spring from users who need new
or enhanced systems.
During the systems planning and selection phase, an organization determines
whether resources should be devoted to the development or enhancement of
each information system under consideration. A feasibility study is conducted
before the second phase of the SDLC to determine the economic and
organizational impact of the system.
• The second task in the systems planning and selection phase is to investigate the
system and determine the proposed system’s scope. The team of systems
analysts then produces a specific plan for the proposed project for the team to
follow. This baseline project plan customizes the standardized SDLC and specifies
the time and resources needed for its execution.
NIELIT Imphal Senapati Extension Centre 17
• The formal definition of a project is based on the likelihood that the
organization’s IS department is able to develop a system that will
solve the problem or exploit the opportunity and determine whether
the costs of developing the system outweigh the possible benefits.
• The final presentation to the organization’s management of the plan
for proceeding with the subsequent project phases is usually made by
the project leader and other team members.

NIELIT Imphal Senapati Extension Centre 18

Phase 2 -Systems Analysis :
• Phase of the SDLC in which the current system is studied and alternative replacement systems are
proposed
• The second phase of the systems development life cycle is systems analysis. During this phase, the
analyst thoroughly studies the organization’s current procedures and the information systems used to
perform tasks such as general ledger, shipping, order entry, machine scheduling, and payroll. Analysis
has several subphases. The first subphase involves determining the requirements of the system. In
this subphase, you and other analysts work with users to determine what the users want from a
proposed system. This subphase involves a careful study of any current systems, manual and
computerized, that might be replaced or enhanced as part of this project. Next, you study the
requirements and structure them according to their interrelationships, eliminating any redundancies.
As part of structuring, you
generate alternative initial designs to match the requirements. Then you compare these alternatives
to determine which best meets the requirements within the cost, labor, and technical levels the
organization is willing to commit to the development process. The output of the analysis phase is a
description of the alternative solution recommended by the analysis team. Once the
recommendation is accepted by the organization, you can make plans to acquire any hardware and
system software necessary to build or operate the system as proposed.
NIELIT Imphal Senapati Extension Centre 19
Phase 3 - Systems Design :
• Phase of the SDLC in which the system chosen for development in systems
analysis is first described independently of any computer platform, (logical
design) and is then transformed into technology-specific details (physical design)
from which all programming and system construction can be accomplished.
• The third phase of the SDLC is called systems design. During systems design,
analysts convert the description of the recommended alternative solution into
logical and then physical system specifications. You must design all aspects of the
system from input and output screens to reports, databases, and computer
processes. Logical design is not tied to any specific hardware and systems
software platform. Theoretically, the system you design could be implemented on
any hardware and systems software. Logical design concentrates on the business
aspects of the system; that is, how the system will impact the functional units
within the organization. Figure below shows both the logical design for a product
and its physical design, side by side, for comparison. You can see from the
comparison that many specific decisions had to be made to move from the logical
model to the physical product.

NIELIT Imphal Senapati Extension Centre 20

Figure shows both the logical design for a product and its physical
design
NIELIT Imphal Senapati Extension Centre 21
• The situation is similar in information systems design. In physical design, you turn the
logical design into physical, or technical, specifications. For example, you must convert
diagrams that map the origin, flow, and processing of data in a system into a structured
systems design that can then be broken down into smaller and smaller units for
conversion to instructions written in a programming language. You design the various
parts of the system to perform the physical operations necessary to facilitate data
capture, processing, and information output. During physical design, the analyst team
decides which programming languages the computer instructions will be written in, which
database systems and file structures will be used for the data, and which hardware
platform, operating system, and network environment the system will run under. These
decisions finalize the hardware and software plans initiated at the end of the analysis
phase. Now you can acquire any new technology not already present in the organization.
The final product of the design phase is the physical system specifications, presented in a
form, such as a diagram or written report, ready to be turned over to programmers and
other system builders for construction.

NIELIT Imphal Senapati Extension Centre 22

Phase 4 -Systems Implementation and
Operation :
• Final phase of the SDLC, in which the information system is coded, tested, and installed in the
organization, and in which the information system is systematically repaired and improved
• The final phase of the SDLC is a two-step process: systems implementation and operation. During
systems implementation and operation, you turn system specifications into a working system that is
tested and then put into use. Implementation includes coding, testing, and installation. During coding,
programmers write the programs that make up the system. During testing, programmers and analysts
test individual programs and the entire system in order to find and correct errors. During installation,
the new system becomes a part of the daily activities of the organization. Application software is
installed, or loaded, on existing or new hardware; then users are introduced to the new system and
trained. Begin planning for both testing and installation as early as the project planning and selection
phase, because they both require extensive analysis in order to develop exactly the right approach.
Systems implementation activities also include initial user support such as the finalization of
documentation, training programs, and ongoing user assistance. Note that documentation and
training programs are finalized during implementation; documentation is produced throughout the life
cycle, and training (and education) occurs from the inception of a project.
NIELIT Imphal Senapati Extension Centre 23
System documentation considerations –
Principles of systems documentation
• Software development benefits from philosophies and principles such
as DRY(Don't repeat yourself), KISS(keep it simple, stupid), code
reuse, and many more. With these commonly understood and
accepted standards, developers can hold themselves and each other
accountable to producing high-quality code.
• This set of principles seeks to define similar standards for
software documentation that, when practiced, will foster clean and
intuitive content. The end goal is ultimately to delight and empower
readers by making information easier for them to acquire.

NIELIT Imphal Senapati Extension Centre 24

All documentation
In general, documentation should be…
• Precursory
• Participatory

NIELIT Imphal Senapati Extension Centre 25

Precursory
• Begin documenting before you begin developing.
• Before coding, write requirements and specifications that
also serve as the first draft of documentation. These texts no
doubt will need a bit of clean up before publishing, but by
front-loading the documentation, you lay a clear path
forwards. Early documentation also helps facilitate peer
feedback and group decisions to guide your work. This model
is the sentiment behind documentation driven design.
NIELIT Imphal Senapati Extension Centre 26
Participatory
• In the documentation process, include everyone from developers to end users.
• Integrate documentation into the standard workflow of developers, and seek to
reduce silos that solicit documentation from only a subset of the software’s
contributors. Developers and engineers are the people with the best access to in-
demand information, and getting them to document it will help foster a culture of
documentation.
• As well, documentation readers (i.e., users) should have clear avenues towards
involvement in documentation. A good first step is to give readers the ability to
offer feedback in the form of comments or suggestions. Allowing readers to edit
documentation directly (e.g., in a wiki) can also be effective but must be weighed
against the need and capacity for editorial oversight.
• Encourage everyone to become a documentarian!

NIELIT Imphal Senapati Extension Centre 27

Content
• “Content” is the conceptual information within documentation.
• Content should be…
• ARID
• Skimmable
• Exemplary
• Consistent
• Current

NIELIT Imphal Senapati Extension Centre 28

ARID
• Accept (some) Repetition In Documentation.
• If you want to write good code, Don’t Repeat Yourself. But if you adhere strictly to
this DRY principle when writing documentation, you won’t get very
far. Some amount of business logic described by your code will need to be
described again in your documentation.
• In an ideal world, an automated system would generate documentation from the
software’s source code, and the system would be smart enough to
generate good documentation without any additional input. Unfortunately we do
not (yet) live in that world, and today the best documentation is hand-written,
which means that just by writing any documentation, you are repeating yourself.
Sure, documentation generators exist and are useful, but it’s important to
acknowledge that they still require input from humans to function.
NIELIT Imphal Senapati Extension Centre 29
• The pursuit of minimizing repetition remains valiant! ARID does not
mean WET (write every time", "write everything twice", "we enjoy
typing" or "waste everyone's time“), hence the word choice. It
means: try to keep things as DRY as possible but also recognize that
you’ll inevitably need some amount of “moisture” to produce
documentation.
• Cultivating an awareness of this inconvenient truth will hopefully be a
helpful step toward reminding developers that a need often exists to
update documentation along with code.

NIELIT Imphal Senapati Extension Centre 30

Skimmable
• Structure content to help readers identify and skip over concepts which they
already understand or see are not relevant to their immediate questions.
• Burying concepts in prose and verbiage demands more time from readers
seeking answers to specific questions. Save your readers’ time by writing
like a newspaper instead of a novel.
• Specifically:
• Headings — should be descriptive and concise.
• Hyperlinks — should surround words which describe the link itself (and never
phrases like “click here” or “this page”).
• Paragraphs and list items — should begin with identifiable concepts as early
as possible.
NIELIT Imphal Senapati Extension Centre 31
Exemplary
• Include (some) examples and tutorials in content.
• Many readers look first towards examples for quick answers,
so including them will help save these people time. Try to
write examples for the most common use cases, but not for
everything. Too many examples can make the
documentation less skimmable. Also, consider separating
examples and tutorials from more dense reference
information to further help readers skim.
NIELIT Imphal Senapati Extension Centre 32
Consistent
• Use consistent language and formatting in content.
• The more content editors you have, the more important a style
guide becomes in facilitating consistency. Consistency also helps make
documentation skimmable and beautiful.

NIELIT Imphal Senapati Extension Centre 33

Current
• Consider incorrect documentation to be worse than missing
documentation.
• When software changes faster than its documentation, the users suffer.
Keep it up to date.
• Make every effort to write content that is version-agnostic and thus in less
need of maintenance. For example, generalize version numbers of software
when they occur in tutorials (such as extracting a source code tarball with
the version number in the file name).
• Be aware as well that some users will remain on older versions of your
software, and thus require older versions of your documentation. Proper
documentation platforms will accommodate such needs gracefully.
NIELIT Imphal Senapati Extension Centre 34
Sources
• A “source” refers to a system used to store and edit content. Examples
of sources include: text files written using reStructuredText or
Markdown, HTML content in a CMS database, help text stored within
strings in application code, code comments to be assembled later into
formalized documentation, and others too.
• All sources should be…
• Nearby
• Unique

NIELIT Imphal Senapati Extension Centre 35

Nearby
• Store sources as close as possible to the code which they document.
• Give developers systems which allow them to easily make
documentation changes along with their code changes. One way is to
store documentation content in comment blocks within application
source code. Another is to store it in separate text files but within the
same repository as the application’s source code. Either way, the goal
is merge (as much as possible) the workflows for development and
documentation.

NIELIT Imphal Senapati Extension Centre 36

Unique
• Eliminate content overlap between separate sources.
• Storing content in different sources is okay, as long as the scope of
each source is clearly defined and disjoint with other sources. The
goal here is to prevent any parallel maintenance (or worse — lack of
maintenance) of the same information across multiple sources.

NIELIT Imphal Senapati Extension Centre 37

Publications
• A “publication” refers to a single, cohesive tool that readers use to consume
documentation. It may be static or interactive — digital or paper. Multiple publications may
be created from a single source (such as web and PDF versions of the same manual).
Although rarer, multiple sources may be used to create a single publication. More examples
of publications include: API reference, man page, command line ``–help`` output, in-
application help tips, online tutorials, internal engineering manuals, and others too.
• Each publication should be…
• Discoverable
• Addressable
• Cumulative
• Complete
• Beautiful

NIELIT Imphal Senapati Extension Centre 38

Discoverable
• Funnel users intuitively towards publications through all likely
pathways.
• Try to identify everywhere the user might go looking for
documentation, and in all of those places, insert helpful pointers for
them to find it. Documentation need not exist in all of these places,
just pointers to it.
• If a user manual is published in the woods, and no one is around to
read it, does it exist? Discoverability says “no”.

NIELIT Imphal Senapati Extension Centre 39

Addressable
• Provide addresses to readers which link directly to content at a
granular level.
• The ability to reference specific sections deep within a body of
documentation facilitates productive communication about the
documentation, even with one’s self. These addresses can take the
form of URLs, page numbers, or other forms depending on the
publication medium. Readers may wish to bookmark certain sections,
share them with other users, or provide feedback to the authors. The
more granular this ability, and the easier it is to access, the better.

NIELIT Imphal Senapati Extension Centre 40

Cumulative
• Content should be ordered to cover prerequisite concepts first.
• Can a reader follow your entire body of documentation, linearly, from start to
finish without getting confused? If so, the documentation is perfectly
“cumulative”, which is great, but not always possible. It’s something to strive for,
especially in tutorials and examples. If you have separated your tutorials and
examples from the reference documentation, then put the tutorials and examples
first. Then, content within the reference information section may be ordered
alphabetically or topically without regard to prerequisite needs.
• The goal of cumulative ordering is not to encourage readers to consume your
documentation linearly — rather it is to help them narrow their search for
information when filling in gaps in their knowledge. If a reader arrives
with some knowledge of the software and begins reading the documentation at
the 25% mark, they are likely to “rewind” when confused.

NIELIT Imphal Senapati Extension Centre 41

Complete
• Within each publication, cover concepts in-full, or not at all.
• Picture some documentation of software like a map of a neighborhood. If
the map displays roads, readers will expect it to display all roads (which exist
and are of the same type being displayed). Perhaps the map does not
display railroads, for example. Thus, a reader approaching the map to look
for railroads will find zero and then seek a different map — but the map is
still “complete”, even with this shortcoming. “Complete” does not mean that
the map must describe all characteristics of the land. It means simply that,
for the characteristics it chooses to describe, it should describe all of them.
A map that displays fifty out of one hundred fire hydrants in a neighborhood
is worse than a map which displays none.
NIELIT Imphal Senapati Extension Centre 42
• As a good example, iconv is a command line tool for working with
character encodings. Its man page covers all of its available options
but none of the possible character encodings accepted as values to
these options. Instead, the man page instructs the user to run iconv -l
to produce a list of character encodings. In this example, the man page
and the list are separate publications, both of which are complete,
which is good!

• Publishing partially completed documentation must be done

cautiously. To avoid misleading readers, make every effort to clearly
state, up front, that a particular concept is only covered partially.

NIELIT Imphal Senapati Extension Centre 43

Beautiful
• Visual style should be intentional and aesthetically pleasing.

• Aesthetics don’t matter to everyone — but (consciously or not) some

readers will struggle to find comfort in documentation that lacks
attention to visual style. Even in text-only documentation such as --
help output, visual style is still present in the form of spacing and
capitalization. If visual style is not important to you personally, then
consider soliciting stylistic improvements from others for whom it is.

NIELIT Imphal Senapati Extension Centre 44

Body
• A “body” refers to the collection of all the publications within a
software project and any of its sub-projects
• A documentation body should be…
• Comprehensive

NIELIT Imphal Senapati Extension Centre 45

Comprehensive
• Ensure that together, all the publications in the body of documentation can
answer all questions the user is likely to have.
• We can never create enough documentation to satisfy all questions,
however obscure, that might arise from users — but satisfying
the likely questions is certainly attainable and thus should be the goal of a
body of documentation. “Likely” is admittedly a blurry term, but it’s also
relative, which means that a body of documentation which answers very
unlikely questions while failing to answer likely ones is somewhat out of
balance.
• Answering some questions may require the user to read multiple
publications, which is okay.

NIELIT Imphal Senapati Extension Centre 46

Types of documentation and their importance
• In one sense, every information systems development project is unique
and will generate its own unique documentation. In another sense,
though, system development projects are probably more alike than they
are different.
• Each project shares a similar systems development life cycle, which
dictates that certain activities be undertaken and that each of those
activities be documented. Specific documentation will vary depending on
the life cycle you are following, and the format and content of the
documentation may be mandated by the organization you work for. Start
developing documentation elements early, as the information needed is
captured.
NIELIT Imphal Senapati Extension Centre 47
Types of documentation in system:
• system documentation and
• user documentation

NIELIT Imphal Senapati Extension Centre 48

• SYSTEM DOCUMENTATION
• records detailed information about a system’s design specifications,
its internal workings, and its functionality. System documentation
can be further divided into internal and external documentation.
• INTERNAL DOCUMENTATION
• is part of the program source code or is generated at compile time.
• External documentation includes the outcome of all of the
structured diagramming techniques, such as data-flow and
entity-relationship diagrams.

NIELIT Imphal Senapati Extension Centre 49

• USER DOCUMENTATION
• is written or other visual information about how an application system works
and how to use it. Although not part of the code itself, external
documentation can provide useful information to the primary users of system
documentation—maintenance programmers.
• For example, data-flow diagrams provide a good overview of a system’s
structure. In the past, external documentation was typically discarded after
implementation, primarily because it was considered too costly to keep up to
date but today’s integrated development environment makes it possible to
maintain and update external documentation as long as desired.

NIELIT Imphal Senapati Extension Centre 50

• Whereas system documentation is intended primarily for
maintenance programmers, user documentation is intended mainly
for users. An organization should have definitive standards on system
documentation.
These standards may include the outline for the project dictionary
and specific pieces of documentation within it. Standards for user
documentation are not as explicit.

NIELIT Imphal Senapati Extension Centre 51

 User Documentation
• User documentation consists of written or other visual information about an
application system, how it works, and how to use it. An excerpt of online user
documentation for Microsoft Visio appears in Figure. The documentation lists the
item necessary to perform the task the user inquired about. The user controls how
much of the help is shown.
• Figure represents the content of a reference guide, just one type of user
documentation. Other types of user documentation include a quick reference
guide, user’s guide, release description, system administrator’s guide, and
acceptance sign-off. Most online reference guides allow you to search by topic area
or by typing in the first few letters of your keyword. Reference guides are great for
specific information (as in Figure) but are not as good for the broader picture of
how to perform all the steps required for a given task. The quick reference guide
provides essential information about operating a system in a short, concise format.
NIELIT Imphal Senapati Extension Centre 52
NIELIT Imphal Senapati Extension Centre 53
• Where computer resources are shared and many users perform
similar tasks on the same machines (as with airline reservation or
mail-order-catalog clerks), quick reference guides are often printed on
index cards or as small books and mounted on or near the computer
terminal. The purpose of a reference guide is to provide information
on how users can use computer systems to perform specific tasks.
• The information in a user’s guide is typically ordered by how often
tasks are performed and how complex they are. Increasingly, software
vendors are using Web sites to provide additional user-guide content.

NIELIT Imphal Senapati Extension Centre 54

• Figure shows the Microsoft Visio
help page. Web-based
documentation allows the vendor to
provide more up-to-date reference
material without issuing new
software CDs. Because most
software is reissued as new features
are added, a release description
contains information about a new
system release, including a list
of complete documentation for the
new release, features and
enhancements, known problems and
how they have been dealt with in the
new release, and information about
installation.

NIELIT Imphal Senapati Extension Centre 55

• A system administrator’s guide is intended primarily for a
particular type of user—those who will install and administer a
new system—and contains information about the network on
which the system will run, software interfaces for peripherals
such as printers, troubleshooting, and setting up user accounts.
Finally, the acceptance sign-off allows users to test for proper
system installation and then signify their acceptance of the new
system and its documentation with their signatures.

NIELIT Imphal Senapati Extension Centre 56

Importance of documentation for the
developer
• Each function in a piece of software solves a specific problem. Before you try to solve any
problem, you should have a good understanding of exactly what the problem is. It makes
no sense just to start writing and then, afterwards, look at what you have come up with to
see whether it solves any useful problem!
• Inexperienced computer programmers imagine that they can keep all problem descriptions
in their heads. Experience has shown that they can't. Three issues come up.
1. When writing a function definition without written documentation, you only have a
rough idea of what it is supposed to do. While you write, the idea morphs in your
head. A simple interruption can cause the idea to lose what focus it has. You start
thinking about the program as a whole instead of thinking of just the function that
you are working on, and the function starts to take on responsibilities that it should
have nothing to do with.

NIELIT Imphal Senapati Extension Centre 57

2. Suppose that you test the function and find that it does not work. So
you need to fix it. But during the process of fixing it, you have nothing
but your memory telling you want the function is supposed to do. It is
difficult to keep that in your head along with the details of how the
function is supposed to work, and the process of fixing a function
definition takes the function further away from its original intent.
3. Later, when you need to use that function, you have forgotten just
what it does. Unwilling to reverse-engineer it, you make a guess based on
what you remember. You often forget important details, and your
software does not work because of it. You are faced with laborious
debugging to find out what is going on.

NIELIT Imphal Senapati Extension Centre 58

Importance of documentation for the
maintainer
• You might have heard of "self-documenting code". The idea is for
functions to be written in a readable form so that, to find out what a
function does, you just read the function's definition. For very small
pieces of software that can be achieved. But imagine a larger piece of
software, say with about 1000 functions. Such software is built up
function upon function; one function typically uses a few others that
are defined in the same collection of 1000 functions, with the
exception of the bottom-level functions that only use the library.

NIELIT Imphal Senapati Extension Centre 59

• Suppose that the software has no internal documentation, and relies
on "self-documenting code". Now you want to understand what a
particular function does. But it uses 3 other undocumented functions,
so you need to understand what they do first. Each of those uses 2
undocumented functions, so you must read their definitions too. It
goes on and on. You find yourself reading thousands of lines of code
to understand a single function whose body is only ten lines long.
• The only way that anyone can work with undocumented software is
to reverse-engineer the whole thing and add documentation that
should have been written by the developer. Most of the time, that is
too difficult. Undocumented software is often just thrown away as
unmaintainable.
NIELIT Imphal Senapati Extension Centre 60
Enforcing documentation discipline in an
organization
• Documentation discipline should be enforced in an organization. All
employees should have a habit of making proper documentation of/in their
work.
• Lets say, How documentation required in Software developer’s work :
• First, Developer must have a proper SRS( software requirement specification) before
writing to code.
• Developer should write proper comments in his code because it will be easier for the
other developer(who will work next on the same code) to understand the existing
code in a better way.
• It is developers responsibility to properly document their software’s working means,
how the software’s functionality works, prerequisite for the software etc.
NIELIT Imphal Senapati Extension Centre 61
• Documentation management is necessary for organization because :
• Increase Collaboration & Communication
• Reliable Document Version Control
• Increase Time-Cost Savings
• Eases Accessibility
• Increase Productivity

NIELIT Imphal Senapati Extension Centre 62

So now the question is, How can we enforce Documentation discipline in an
organization ?
• organization should consider it as integral part of work.
• Proper resources should be made available to build document management
system whether its human resource or technical resource
• procedures should be set up to create or review documentation
• Management should not be lenient on part of documentation, management
should never say like “ as time running short , so just create the system and
make the documentation later”.
• Phase should not be considered complete until documentation is done.
• Coding should not be considered done unless its has required comment lines.

NIELIT Imphal Senapati Extension Centre 63