Module 04

Plan Website and Explain Software Development Life Cycle for

Web Applications

Learning Outcomes
After completion of this learning module, learner will be able to:
 Develop website project plan
 Utilize the software development life cycle in a web project

179
Blank Page

180
 Learning Unit 01

Develop Website Project Plan

Overview Meeting

In this learning unit you will learn about project planning includes arrange- In a meeting, two
ment & management of project meetings, gathering project requirements, or more people
creating story boards, development of time lines and evaluation of finances.
come together to
After completion of this learning unit you will able to define project meetings,
story boarding, financial evaluations, functional and non-functional require- discuss one or
ments and client management. more topics, often
in a formal setting.
Arrange and Manage Project Meetings [1]

Meetings are necessary to coordinate individual efforts, collaborate on joint

projects, garner support for ideas, sell ideas, solve problems collectively, and
make consensus-based decisions.

Elements for effective project meetings

 Why to meet (Objective)
 Whom to meet (Participant)
 When & where to meet (Location & Time)
Objective: for planning a meeting it should have clear objectives for example
to decide the marketing strategy for the product of this year.

Participants: are the people who attend the meeting to accomplish for the
specific purpose? Agenda

Structure: is the procedure for the meeting how to organize it in its best ac- Agenda is a list of
complish to get the specific purpose. Examples: guest speakers, videos, items to be dis-
brainstorming sessions, discussion groups, demonstrations, etc. cussed at a formal
meeting.
Location and Time: Select a meeting place that best matches the partici-
pant’s needs, the objective, and the meeting structure. When planning where
to meet, give consideration to size, comfort, accessibility, adequate parking,
room acoustics, equipment needs, etc.

Agenda: Most important, to distribute to participants at least three days prior

to the meeting day.

181
 An agenda is crucial to meeting success in three ways:

1. It clarifies the objectives.

2. Distributing the agenda prior to the meeting helps participants plan
and prepare to make an effective contribution.
3. During the meeting, the agenda provides direction and focus for the
discussion.

Responsibilities: is a work freedom with limitation, bound under rules.

Confirmation: before the commencement of meeting must confirm.

 Participant availability
 Agenda distribution & authentication
Definition  Place and time
 Arrangement, structure of meeting
A requirement
gathering is an es-
Requirements for a Successful Meeting
sential part of any
project and project  Define the purpose, goals, and objectives of the meeting
management. Un-  Determine the participant
derstanding fully  Create a detailed agenda for the meeting
what a project will  Determine the appropriate time length of the meeting
deliver is critical to  Determine the best meeting format and location
its success. This  Send out the meeting invite and agenda days in advance
may sound like  Facilitate and lead the meeting
common sense, but  Document and summarize action items
 Send out a meeting summary
surprisingly it's an
 Follow up on action items and schedule additional meetings as nec-
area that is often essary
given far too little
attention. Run an Effective Project Meeting

Here are some suggested guidelines on how to run effective meetings:

 Begin on time and end on time.

 Use the Agenda
 .Control dominating individuals.
 Refreshment & beverages.
Do you know!  Compactness.
Gather Project Requirements [2]

Requirement Gath-
A requirement gathering is about creating a clear, concise and agreed set of
ering is also an im- customer requirements that allow to provide exactly what they are looking for.
portant component
of Software Devel- Sources of Requirements
opment Life Cycle Good requirements start with good sources.
(SDLC) Examples of sources of requirements include:
 Customers
Project planning is  Users
part of Project  Administrators and maintenance staff
Management.  Partners
 Domain Experts
 Industry Analysts
 Information about competitors

182
Rules for Successful Requirements Gathering

1. Don't assume what the customer wants, ask.

2. Involve the users from the start.
3. Define and agree the scope of the project.
4. Ensure requirements are specific, realistic and measurable.
5. Gain clarity if there is any doubt.
6. Create a clear, concise and thorough requirements document and
share it with the customer.

7. Confirm the understanding of the requirements with the customer

(play them back).
8. Avoid talking technology or solutions until the requirements are fully
understood.
9. Get the requirements agreed with the stakeholders before the project
starts.
10. Create a prototype if necessary to confirm or refine the customers'
requirements.

Requirements Gathering Techniques

 Conduct a brainstorming session

 Interview users
 Send questionnaires
 Work in the target environment
 Study analogous systems
 Examine suggestions and problem reports
 Talk to support teams
 Study improvements made by users
 Look at unintended uses
 Conduct workshops
 Demonstrate prototypes to stakeholders

Conduct a Brainstorming Session

Definition
Brainstorming is a short group session where everyone is allowed to say
whatever they feel is important to the topic of discussion. After that, a facilita- Brainstorming is a
tor leads the group in organizing and prioritizing the results. method of shared
problem solving in
The following basic rules for brainstorming ensures better results:
which all members
 Start out by clearly stating the objective of the brainstorming session. of a group sponta-
 Generate as may ideas as possible. neously contribute
 Let imagination soar. ideas.
 Do not allow criticism or debate while gathering information.
 Once information is gathered, reshape and combine ideas.

Interview Users

Face-to-face contact with users through individual interviewing is the primary

source of requirements and an important way to gather and validate their re-
quirements. Remember that it is not the only possible technique.

183
 Use the system to make an effort to understand and experience the user's
problem to describe it clearly and correctly.

Send Questionnaires
Questionnaire
Sometimes, face-to-face meetings with stakeholders are not feasible (for ex-
ample: when developing products for the consumer market). In those situa-
Questionnaire a set tions, use questionnaires.
of printed or written Create a set of questions (as per requirement), possibly with multiple choice
questions with a instances, to the relevant stakeholders, and ask them to complete it and re-
choice of answers, turn it to.
devised for the pur-
poses of a survey or
statistical study.

Work In the Target Environment

Working in an open target environment is quite easy than target base envi-
ronment. It would be good to see the same dedication devoted to solving
problems in target based work too. Where the work cannot easily be experi-
enced in this way, it may still be possible to do a bit more than just sit quietly
and observe.

Study Analogous Systems

Analogous
The starting point for many projects is often a similar or an existing system.
Analogous means Sometimes, comparable products and systems contain working versions of
similar or corre- good ideas for solving user problems. Even if they are trying to solve slightly
sponding in some different problems, they often provide valuable clues as to what need to do.
respect.
Such a process might involve the following activities:

 Read the document from seller-end to purchaser-end (several times)

to comprehend what the customer wants and what actually has been
written.
 Classify all of the types of information in the document. (user, system
requirements, design elements, plans, background material, irrele-
vant detail)
 Mark up the original text to separate out such requirements.
 Find a good structure for each of the different types of information
such as: a scenario for the user requirements, functional breakdown
for the system requirements, and architecture for the design.
 Organize the information to show gaps and overlaps.
 Create traceability links between these information elements to show

184
 the designers exactly what the users want.
 Convince the customer to accept the new information as the basis for
the contract.

Examine Suggestions and Problem Reports

Requirements can come from change suggestions and user problems. A di-
rect road to finding requirements is to look at suggestions and problems as
first described. Ask users some questions about these areas to clarify the
users' actual needs.
Talk to Support Teams
Most large sales organizations have a help desk that keeps a log of problems
and fixes, and support engineers who do the fixing. Many organizations have
similar facilities to support their own operations. Also talk to the training team
and installation teams about what users find to be difficult.
Study Improvements Made by Users
Users of a standard company spreadsheet may have added a few fields, or
related different sheets together, or drawn a graph, that exactly meets their
individual needs. For example, a lathe operator may have manufactured a
special clamp, or an arm that prevents movement of the tool beyond a certain
point. Any such modification points to something wrong with the existing
product, which makes it a valid requirement for the new version.
Look at Unintended Uses
People often use things for purposes for which they were not designed. This
is a good way to get new ideas and to think of innovations. For example, an
observant product manager noticed that an engineer was staying in the office
late to use an advanced computer-aided design system to design a new
kitchen layout for his home. Inexpensive commercial products are now widely
available for home use.
Workshop
Conduct Workshops
Workshops can rapidly pull together a good set of requirements. In two to five Workshop is a
days, can create a set of requirements, and then review and improve them. If
everyone in a workshop tries to estimate the cost and value of each require- meeting at which a
ment, the document becomes much more useful and cost-effective. group of people en-
gage in intensive
discussion and activ-
ity on a particular
subject or project.

Workshops are quicker and better at discovering requirements than other

techniques, such as sending questionnaires.

Perform Storyboarding [3]

Storyboarding is an iterative, interaction design methodology that uses a se-

ries of sketches or pictures to demonstrate an end to end solution for a user
scenario.

Storyboards originated in the motion picture industry to help directors and

cinematographers visual a film's scenes in sequence. Such storyboards re-
semble cartoon strips.

185
Storyboarding can strengthen the user experience elements of designs, and
software for building prototypes from those sketches can be an invaluable
tool.

Storyboard for a Web Project

A storyboard is the blueprint for a web project. It is a simple, flexible tool

which can be used to display the elements on a single Web page such as
images, banners, navigation, graphic elements and text. It is also an excel-
lent tool for presenting a project to clients.

Purpose of a Website Storyboard

The purpose of a website storyboard is threefold.

1. It serves as an outline of the design approach.

2. It defines the elements that need to go on each page.
3. It shows the navigational architecture and information flow to the team and
demonstrates how the pages are to work together to provide the user’s inter-
active experience.

Types of Storyboards
Three types of storyboards are detailed below.

Presentation Storyboard. Used to demonstrate visualization of the site and

solidify the design model; can be compared to an architectural sketch of a
new home.

Production Storyboard. Used by production teams to present a clear pic-

ture of what will be happening throughout the entire site, what each page will
look like, and what each team member/developer will do.

Maintenance Storyboard. Used by the production team to present a clear

picture of what parts of the site will need to be updated or maintained, as well
as what parts of the website that should be left alone or modified by a profes-
sional. This is the plan for site upkeep, such as performing homeowner
maintenance.

The storyboard illustration should include:

 A flowchart depicting the opening screen and the major sections of

the website.
 A description of the text that will be placed on each major page of the
website.
 A description of graphic images that belong on each page.
 The navigational tools and their location.
 The cross-links to all of the information contained on the website.
 The external links to other websites.
 The color scheme of the website.

186
Storyboard Checklist
A storyboard can be used to provide the details of an entire website by outlin-
ing the hierarchy or architecture of a site.

Navigation
 Does the site design contain numerous links on every page in an ef-
fort to keep everything “just a click away?” Can they be better orga-
nized?
 Is the navigation weak? Are there few basic links that then lead to
hundreds of wandering links? Do the elements need to be reor-
ganized?
 Does the navigation make sense? Will viewers be able to find their
way to the information they want if they follow the links provided?
 Have links been grouped logically?
 Are there gratuitous pages added: links that lead to another page of
links?
 Is there a way back to the dominant section or home page from the
subsections or do viewers have to use the “back” button on their
browsers?

Site Structure
 Given the complexity of the site is it necessary to add a website
map?
 Are other referral elements such as an index needed? Table of con-
tents? Glossary?
 Are there too many forms that basically perform the same function?
Can they be consolidated?
 Is the site balanced or does the site contain just one really good page
located in a virtual ghost town?
 Graphics
 Is the site overloaded with graphics? Are they necessary? Are they
annoying? Do they go with the content?
 Does the site start with a strong graphic presence, only to putter out
once further into the site?
 Given the number of graphics anticipated per page and per section,
are visitors forced to survive the longest downloads on those pages
which are utilized most frequently?
 Are graphics taking over the page? Does the content get relegated to
a tiny visual space?

Content

187
  Is the “meat” of the content hidden too deep into the site to be found?
 Is the content being updated most frequently easy to get to?
 Are there repeating content elements, such as department Rolodex-
es that would be better combined into one section.
 Are there too many “under constructions” flags?
 Is there too much pointless content, fluff, or dry reading in a more dy-
namic section? *Is there enough technical information in those areas
where it is warranted?
 Does the content logically flow within the section? Between sections?
 If providing a website as a means of answering questions, have
questions been answered or are viewers required to email or call for
more assistance?
 Can the site be created as envisioned or is it too ambitious an under-
taking?

Develop Timelines [4]

Time Line Timelines can use any time scale, depending on the subject and data. A pro-
ject timeline is an important component of time management planning and a
useful project management tool for keeping the client informed and project on
A timeline is a
target.
graphical represen-
tation of a period of
time, on which im-
portant events are
marked.

A project timeline allows an IT project manager to:

 Identify potential problems before they delay the project;

 Give customers earlier notice of potential delays or scope changes -
before over estimate;
 Provide immediate, on-demand status reports regarding which as-
pects of the project are complete, due or running behind;
 Always keep in touch with each project, and whether out and ahead
or behind financially;
 Bill the client as project milestones are attained.
 Track the actual time spent on all aspects of the project, so that, to
make better development in future estimates and timelines.

Budget Evaluate Finances (Budgeting and Costing)[5]

Budget is an esti- Creating a Project Budget
mate of income and
expenditure for a set When starting a project, it is difficult to know how much it will cost. Project
period of time. managers are held to account for their budget estimates and with so much
uncertainty in projects, it can be one of the project managers' greatest chal-
lenges.

188
The ability to create an accurate budget is an essential skill for a project
manager.
Budgeting Basics
There are two main approaches can take when creating a budget:

 Top-down approach: deciding how much the project will cost and
dividing the amount between the work packages.
 Bottom-up approach: estimating the total cost of the project by cost-
ing the lowest-level work packages and rolling up.
Top-Down Budgeting Approach

The decision is made, often by senior management, about how much the pro-
ject should cost. The amount is divided between the work packages. This
approach is more than guessing, it needs to explain how do the work within
the allocated amount of budget on each work package.

Prior experience from other projects will play a part in validating the budget
allocation for work packages. It should be asked whether the budget looks
realistic based on experience from past projects.

The advantage. The top-down budgeting approach is focuses on achieving

the project within the budget allocated and leads to efficiencies and reduction
in wasteful practices.

The disadvantage. The top-down budgeting approach is assumes the per-

son creating the budget has enough knowledge and expertise to make a rea-
sonable cost estimate.

Bottom-Up Budgeting Approach

The team, often involving the final budget holder, identifies the tasks and ac-
tivities needed to complete the project. The project is based on the lowest-
level work packages and rolled up to arrive at the total project cost. The direct
and indirect costs are calculated for each work package.

The advantage. The bottom-up budgeting approach is accurate (as long as

not missed any task or activity). It is good for team morale because the pro-
ject manager involves the team in budget creation. This approach is some-
times called participative budgeting. Cost

The disadvantage. The bottom-up budgeting approach is difficult in getting a Cost is an amount
full list of tasks and activities needed to complete the project. It is easy to that has to be paid
miss some that will be needed and that will later throw the budget out. or spent to buy or
obtain something.
Different Cost Types
There are two cost types that concern project managers when they create
budgets: direct and indirect costs.

Direct Costs
These costs can easily be attributed to the project and are charged to the
project on an item-by-item basis.

189
 Examples are:
 Labor (people)
 Consultant fees
 Raw materials
 Software licenses
 Travel

Indirect Costs
These costs are for items that benefit more than one project, and only a pro-
portion of their total cost is charged to the project.

Examples are:

 Telephone charges
 Office space (rent)
 Office equipment
 General administration
 Company insurance

Functional Re-
Differentiate between Functional Requirements and
quirement
Non-Functional Requirements [6]
A functional re- Requirements may be functional or nonfunctional and both are essential to a
quire- successful software project.
ment defines
a function of Functional Requirements
a system and its
Most requirements definition focuses mainly on functional requirements,
components. A func- which are based upon the expected functioning of the product or system to
tion is described as be created. Functioning typically is equated with product/system features for
a set of inputs, the which might have a menu or button choice, such as: identify a customer, se-
behavior, and out- lect an item to order, and calculate the amount due.
puts.

Non-functional
Requirement

A non-functional
requirement is
Examples of Functional Requirements
a requirement that Functional requirements may be calculations, technical details, data ma-
specifies criteria that nipulation and processing and other specific functionality that define
can be used to judge what a system is supposed to accomplish.
the operation of a
system, rather than Non-Functional Requirements
specific behaviors.
Non-functional requirements are often called qualities of a system. Other
terms for non-functional requirements are "constraints", "quality attributes",
"quality goals", "quality of service requirements" and "non-behavioral
requirements". Non-functional requirements can be divided into two main
categories:

190
  Execution qualities, such as security and usability, which are ob-
servable at run time.
 Evolution qualities, such as testability, maintainability, extensibility
and scalability, which are embodied in the static structure of the soft-
ware system.
Examples of Non-Functional Requirements

 Accessibility
 Capacity, current and forecast
 Compliance
 Documentation
 Disaster recovery
 Efficiency
 Effectiveness
 Extensibility
 Fault tolerance
 Interoperability
 Maintainability
 Privacy
 Portability
 Quality
 Reliability
 Response time
 Robustness
 Scalability
 Security
 Stability
 Supportability
 Testability

Exhibit the Significance of Client Management [7]

Client
Customer Relationship Management (CRM) is a system for managing a
company's interactions with current and future customers. It often involves Client is a person or
using technology to organize, automate, and synchronize sales, marketing, organization using
customer service, and technical support. the services of a
lawyer or other pro-
Managing client expectations is a critical skill in delivering good quality fessional person or
work, which both ends are happy with. Client expectations tie directly into the company.
level of satisfaction a client will receive from the service provider work.
If a client appears to be dissatisfied, the best place to start when looking
for causes, at the client’s level of expectation performance is should at the
outset of the project. Sometimes, even the best management consultants
become so wrapped up in their own work processes that they lose sight of
the expectations a client.

What are the Client’s Expectations?

Key is asking questions. For example, if a client has hired the consultant to
help grow their business, ask questions about like,

 “How much growth?”

 “Over what time period to grow?”
 “What is a realistic percentage of growth?”

191
However, a client may not always verbalize their expectations. These
are implicit expectations (that client holds only with self). These expectations
are based upon several things:

 Client organization standards and culture

 Industry standards and quality benchmarks
 Personal reputation,
 Articulation of what is expected

Don’t Promise What Can’t Deliver

The client may want to perform tasks that cannot be performed, or the
time frame may make it nervous. Whatever do / do not promise things
that cannot be delivered on.

Prevention
As a final note, it is important to be sure that both ends are on the same
page when it comes to their expectations. Be sure to check, and double
check to make sure that no minor miscommunication gets in the way of
the success of a project. Never make any assumptions.

192
 Learning Unit 02

Utilize the Software Development Life-cycle in a Web Project

Overview

SDLC
In this learning unit learner will be introduced about overall direction that the project
will take to creation of project strategy documents, break down the deliverables into
more detailed business / client requirements. The software devel-
After this Learning unit the learner will able to define and implement Software Devel- opment life cycle is a
opment Life Cycle (SDLC). sequence of events
in software devel-
Recount software development life cycle: opment describing
tasks performed at
each step.
The software development life cycle (SDLC) is a sequence of events in software de-
velopment describing tasks performed at each step. SDLC is a structure followed by a
development team within the software organization. It consists of a detailed plan de-
scribing how to develop, maintain and replace specific software. The Software Devel-
opment Life Cycle defines a methodology for improving the quality of software and the
overall development process.
Analysis
Phase

Maintenan
Design
ce

Implement
Testing
ation

System Development Lifecycle Steps

Carry out the Project Analysis Phase [1]

The Analysis Phase is where the project lifecycle begins. The Analysis Phase is break
down the deliverables in the high-level Project Charter into the more detailed business
requirements. The Analysis Phase is also the part of the project where identify the
overall direction that the project will take through the creation of the project strategy
documents.

Series of steps followed by developers are:

1. Collection of Facts: End user requirements are obtained through documentation,
client interviews, observation and questionnaires,
2. Scrutiny of the existing system: Identify pros and cons of the current system in-
place, so as to carry forward the pros and avoid the cons in the new system.
3. Analyzing the proposed system: Solutions to the shortcomings in step two are
found and any specific user proposals are used to prepare the specifications.

193
 Design Phase [2]

Based on the client’s need and the detailed analysis of the existing system, the new
system must be designed. This is the phase of system designing. It is the most crucial
phase in the developments of a system. The logical system design arrived at as a re-
sult of systems analysis is converted into
 Preliminary or General Design
 Structured or Detailed Design
There are several tools and techniques used for describing the system design of the
system. These tools and techniques are:

 Flowchart
 Data flow diagram (DFD)
 Data dictionary
Implementation  Decision table
Implement / coding  Decision tree
the Project: Based
Implementation Phase [3]
on the client’s need
and the detailed
analysis of the exist- In this stage physical system specifications are converted into a working and reliable
ing system, the new solution. This is where the system is developed. It is followed by testing and then im-
system must be de- plementation.
signed. This is the
phase of coding the Steps in Implementation Phase:
software. 1. Coding:
2. Integration and Testing
3. Installation:
Testing
Testing Phase [4]
Testing is the pro- Testing Phase provides only a shorter version of the testing techniques.
cess of evaluating a Testing is the process of evaluating a system or application, to check whether the ap-
system or applica- plication meets all requirements of the client and to detect the errors. There are two
tion to check wheth- phases.
er the application
 Static Testing
meets all require-  Dynamic Testing
ments of the client o Structural (or) white box testing
and to detect the o Functional (or) Black Box testing.
errors.
Maintenance & Support phase [5]
Maintenance is necessary to eliminate errors in the system during its working
life and to tune the system to any variations in its working environments. It
has been seen that there are always some errors found in the systems that
must be noted and corrected. It also means the review of the system from
time to time. The review of the system is done for:
 Knowing the full capabilities of the system
 Knowing the required changes or the additional requirements
 Studying the performance.

194
If a major change to a system is needed, a new project may have to be set
up to carry out the change. The new project will then proceed through all the
above life cycle phases.

Summary of Module
 Arranging and managing project meetings is very important in devel-
opment of the software to gather the project requirements and Per-
forming storyboarding Develop timelines.

Evaluation of finances (budgeting and costing) is the technique that

how to manage entire project in available financial resource.

Identification of functional and non-functional requirement play vital

role in any project.

 Software Development life cycle (SDLC) is a framework to develop

software. It helps you to analyze, execute, deploy and maintain the
software.

195
Frequently Asked Questions (FAQs)
What is the significance of project meetings in project
FAQ 1:
planning?
Meetings are necessary to coordinate individual efforts, collabo-
rate on joint projects, garner support for ideas, sell ideas, solve
Answer
problems collectively, and make consensus-based decisions.

FAQ 2: Name different sources of requirements

Customers, Users, Administrators, Maintenance Staff, Partners,
Answer
Domain Experts, Industry Analysts and Competitors.
FAQ 3: Explain the purpose of storyboarding
It serves as an outline of the design approach. Defines the ele-
ments that need to go on each page and shows the navigational
architecture and information flow to the team and demonstrates
Answer
how the pages are to work together to provide the user’s inter-
active experience.

What is the difference between functional and non-

FAQ 4:
functional requirements?
Functional requirement defines a function of a system and its
components and a non-functional requirement is a requirement
Answer
that specifies criteria that can be used to judge the operation of
a system, rather than specific behaviors.
FAQ 5: What are the main budgeting approaches?
Top-down approach & Bottom-Up Budgeting Approach
Answer

FAQ 6: What are the different phases in SDLC?

There are 5 phases in Software Development Life Cycle:

1. Analysis
Answer 2. Design
3. Coding
4. Testing
5. Maintenance
FAQ 7: What is Software Life Cycle?
Software life cycle comprise the total life of the software devel-
oped right from the time of initial development to the time it is
Answer scrapped out or terminated. This includes the development
phases, revisions and upgrades and if necessary adding it up
with other software project as well.

Is it mandatory to implement SDLC methods while develop-

FAQ 8: ing any type of software project?

This is a tricky question and must be tackled smartly. Yes it can sure
implement SDLC approaches for every type of software need to de-
velop. But it is not a cost effective solution for smaller projects. For
Answer
every kind of software development needs different approach and so-
lution and must not be considered to be developed under mandatory
SDLC guidelines.

FAQ 9: Can I build a software project without SDLC models?

Of course. There is no hard and fast requirement for a develop-

Answer
er to implement any SDLC model for developing a software pro-

196
 ject. The ability to simplify project into modules and ascertain
correct progression for completion is the only reason for which
SDLC models and methodology was designed in the first place.
Work without SDLC is the biggest challenge and there won’t be
any specific process to organized work.
Which types of software’s are used to upload / manage the
FAQ 10:
files / folders on web servers?
FTP Client software types are used to upload / manage the
Answer
folders and files on web server.

197
Test Yourself!
Please mark the correct one from the given options.

Which one of the following is NOT a non-functional require-

1.
ment?

a. Documentation b. Interoperability

c. Efficiency d. Login Facility

Which of the following is a (an) requirement gathering tech-

2.
nique?

a. Coding b. Support

c. Design d. Interview users

3. What is Analogy?

a. Similar b. Opposite

c. Different d. Diverse

4. Which is not a Storyboard?

a. Presentation b. Production

c. Maintenance d. Configuration

5. Expectations of Clients does not include

a. Respect b. Communication

c. Aggression d. Feedback

6. What is full form of SDLC?

a) System Design Life cy- b) Software Design Life

a. b.
cle Cycle

c) System Development Software Development Life

c. d.
Life Cycle Cycle
Which tool and technique is NOT used for describing the sys-
7.
tem design?

a. Flow Chart b. Data Flow Diagram (DFD)

198
 c. Spiral Model d. Decision Table

Which phase is necessary to eliminate errors in the system

8.
during its working?

a. Analysis b. Deployment Phase

C Design Phase D Maintenance Phase

9. Which one IS the FTP Client software from the following?

A FileZilla b Microsoft Word

c Adobe Acrobat Reader d Google Chrome

199
Answers Key

MCQ Number Correct Answer

1 D

2 D

3 A

4 D

5 C

6 B

7 C

8 B

9 A

200