FEDERAL UNIVERSITY DUTSE

Faculty of Science
Department of Computer Science

FIRST SEMESTER EXAMINATIONS 2017/2018 ACADEMIC SESSION

Course Title: Software Engineering
Course Code: CSC 403 Date of Exam: 15th February, 2018
No. Of Credits: Four (4) Time of Exam: 7:30am - 10:30am
Course Status: Compulsory Time Allowed: 3 Hours
Level: 400 Venue: CSC LR 3

Instructions: Answer any Five (5) Questions. All questions carry equal marks.

Question One:

(a) Differentiate between module and software component. [3 Marks]

(b) What factors generally influence the process of selecting a programming language out of the many options
available for coding an application? [5 Marks]
(c) What do you understand by the terms software engineering? Also, discuss the importance of software
engineering for software development. [6 Marks]

Question Two:
(a) What is the significance of software crises in references to software engineering discipline?[7 marks]
(b) What do you do in the requirement analysis phase of a software development life cycle? Explain in detail
problem analyzing part with SRS. [7 marks]

Question Three:
(a) Write the name of various software life cycle models. Explain the prototype model. Under what
circumstances is it beneficial to construct a prototype model? [7 marks]
(b) Briefly discuss the following:
i. Conceptual Design and Technical Design [ 3.5 Marks]
ii. Module Coupling and Module Cohension [ 3.5 Marks]

Question Four:
(a) Describe the role of management in software development with the help of example. [6 Marks]
(b) Briefly discuss the following:
[i]. Test case design [2 Marks]
[ii]. White-box and Black-box Testing [3 Marks]
[iii]. Alpha, Beta and Acceptance Testing [3 Marks]

Page 1 of 24
Question Five:
(a) What is coding style? Describe the various programming style for good coding of a program. [6 Marks]
(b) List the name of common risks that encounter in most software project and explain any two of them.
[6 Marks]
(c) What do you understand by project cost estimates? [2 Marks]

Question Six:
(a) Define the software maintenance. Also, discus the problem associated with software maintenance. [7 Marks]
(b) What is software quality? Describe the software quality factors proposed by Mc-Call. [7 Marks]

Question Seven:
(a) Discuss the CASE tools? How does CASE support in software life cycle? [7 Marks]
(b) What are different types certifications? Explain the significant of each type and which one is most important for
the end user? [7 Marks]

Page 2 0f 20
Question 1:

(a) Differentiate between module and software component. [1.5 + 1.5 Marks]

Answer:

MODULAR

The concept of modularity leads every software designer to a fundamental question. How do we decompose a software
solution to obtain the best set of modules? A modular design reduces complexity, facilitates change and results in easier
implementation by encouraging parallel development of different parts of a system. There are many definitions of the
term “module”. They range from “a module is a FORTRAN subroutine” to “procedures and functions of PASCAL and C”,
to “C++/Java Classes” to “Java packages” to “a module is a work assignment for an individual programmer”. All of these
definitions are correct. The concept of functional independence is a direct outgrowth of modularity. Functional
independence is achieved by developing modules with single minded function. Software with effective modularity is
easier to develop because function may be compartmentalized and interfaces are simplified. Independent modules are
easier to maintain. Functional independence is a key to good design and design is the key to software quality.
Independence is measured using two qualitative criteria – cohesion and coupling.

Software consists of programs, documentation of any facet of the program and the procedures used to setup and
operate the software system. The components of the software systems are shown in Fig 1.1.

Program

Documentation Operating
procedures

Fig. 1.1: Software = Program +Documentation + Operating Procedure

Any program is a subset of software and it becomes software only if documentation and operating procedure manuals
are prepared. Program is a combination of source code and object code. Documentation consists of different types of
manuals as shown in Fig. 1.2.

Page 3 of 24
 Design

Testing Implementation Design Analysis /specification

Test Result Cross- Source Code Entity –

Test Data Flow charts Data Flow Context - Formal
Referencing Listings Relationship
List diagram Diagram Specification
diagrams

Fig. 1.2: Documentation manuals

Operating procedures consists of instructions to setup and use the software system and instructions on how to react to
system failure. List of operating procedure manuals/documents is given in Fig. 1.3.

Operating System

User Manual
Operational Manual

Reference Guide System Over View

Operational Manual Installation Guide
Beginner’s Guide
Toturial

Fig. 1.3: List of Operating system procedure Manuals

(b) What factors generally influence the process of selecting a programming language out of the many options available
for coding an application? [05 Marks]

Answer:

SELECTING A LANGUAGE FOR CODING AN APPLICATION

One is often faced with the situation of selecting a programming language, out of the many options available for coding
an application. The following factors generally influence the selection process:

1. Nature of the application: The language should be suitable for the application area. For example, FORTRAN is
suitable for scientific and engineering applications, while COBOL is suitable for business applications.
2. Familiarity with the language: If there are multiple languages, which are found suitable for the application area,
the language selected should be one that is best known to the programmers who are going to code the
application.

Page 4 of 24
 3. Ease of learning the language: If there are multiple languages, which are found suitable for the application area,
and if programmers are not familiar with any of them, the language, which is easier to learn and use, should be
selected.
4. Availability of program development tools: Before selecting a language, one must also find out whether the
language is well supported with good program development tools like compiler, interpreter, debugger, linker,
etc. The time and effort needed for the coding the application can be greatly reduced, if the selected language is
supported with good program development tools.
5. Execution efficiency: If the execution efficiency of the application is important, one many use an assembly
language, instead of high-level language for coding the application. This is because an assembly language
program written by a clever programmer usually has a shorter production run time, and takes less storage space
than does a program of the same application written in a high-level language.
6. Features of a good programming language: Finally, the features of a good programming language discussed in
the previous selection often influence the selection process.

(c) What do you understand by the terms software engineering? Also, discuss the importance of software engineering
for software development. [03 + 03 Marks]

Answer:

DEFINITION

At the first conference on software engineering in 1968, Fritz Bauer [FRIT68] defined software engineering as “The
establishment and use of sound engineering principles in order to obtain economically developed software that is
reliable and works efficiently on real machines”. Schach [SCHA90] defined the same as “A discipline whose aim is the
production of quality software, software that is delivered on time, within budget, and also satisfies its requirements.

Both the definitions are popular and acceptable to majority. However, due to increase in cost of maintaining software,
objective is now shifting to produce quality software that is maintainable, delivered on time, within budget, and also
satisfies its requirements.

The main objective of software engineering is to produce good quality software with minimum cost and within the
limited allowed time period.

IMPORTANCE OF SOFTWARE ENGINEERING

Now-a-days, software engineering is playing very important role for software development. Today, software developing
companies have realized the difference between software and a small program. A small program can be developed
without software engineering but it is very difficult to develop the software, means collection of large program in a
single package without software engineering. Today, software engineering is becoming more important because
developers and managers are asking the following questions:

 Why is it that there is always some gap between what the software needs to do and what is actually does?

 Why does it take so long to develop software?

 Why are software costs so high?

 Why software has numbers of errors?

Page 5 of 24
  Why is it so messy to maintain software?

 Why is it that schedules and cost estimates of software projects are almost always incorrect?

 Why do we have difficulty in measuring progress as software is being developed?

 Why cannot we find all errors?

Software engineering is able to provide the answers of the above questions.

Question Two:

(a) What is the significance of software crises in references to software engineering discipline? [07 Marks]

Answer:

Software Crises

1. Software is easy to change: It is true that source code files are easy to edit, but that is quite different than
saying that software is easy to change. This is deceptive precisely because source code is so easy to alter. But
making changes without introducing errors is extremely difficult, particularly in organizations with poor process
maturity. Every change requires that the complete system be re-verified. If we do not take proper care, this will
be an extremely tedious and expensive process.

2. Computers provide greater reliability than the devices they replace: It is true that software does not fail in the
traditional sense. There are no limits to how many times a given piece of code can be executed before it “wears
out”. In any event, the simple expression of this myth is that our general leaders are still not perfectly accurate,
even though they have been computerized. Back in the days of manual accounting systems, human error was a
fact of life. Now, we have software error as well.

3. Testing software or “proving” software correct can remove all the errors: Testing can only show the presence
of errors. It cannot show the absence of errors. Our aim is to design effective test cases in order to find
maximum possible errors. The more we test, the more we are confident about our design.

4. Reusing software increases safety: This myth is particularly troubling because of the false sense of security that
re-use can create. Code re-use is a very powerful tool that can yield dramatic improvement in development
efficiency, but it still requires analysis to determine its suitability and testing to determine if it works.

5. Software can work right the first time: If we go to an aeronautical engineer, and ask him to build a jet fighter
craft, he will quote us a price. If we demand that it is to be put in production without building a prototype, he
will laugh and may refuse the job. Yet, software engineers are often asked to do precisely this sort of work, and
they often accept the job.

6. Software can be designed thoroughly enough to avoid most integration problems: There is an old saying
among software designers:”too bad, there is no compiler for specification”: This point out the fundamental
difficulty with detailed specifications. They always have inconsistencies, and there is no computer tool to

Page 6 of 24
 perform consistency checks on these. Therefore, special care is required to understand the specifications, and if
there is an ambiguity, that should be resolved before proceeding for design.

7. Software with more features is better software: This is, of course, almost the opposite of the truth. The best,
most enduring programs are those which do one thing well.

8. Addition of more software engineers will make up the delay: This is not true in the most of cases. By the
process of adding more software engineers during the project, we may further delay the project. This does not
serve any purpose here, although this may be true for any civil engineering work.

9. Aim is to develop working programs: The aim has been shifted from developing working programs to good
quality, maintainable programs. Maintaining software has become a very critical and crucial area for software
engineering community.

This list is endless. These myths, poor quality of software, increasing cost and delay in the delivery of the software
have been the driving forces behind the emergence of software engineering as a discipline. In addition, following are
the contributing factors:

 Change in ratio of hardware of maintenance

 Increasing importance of maintenance

 Advances in software techniques

 Increased demand for software

 Demand for larger and more complex software systems.

(b) What do you do in the requirement analysis phase of a software development life cycle? Explain in detail
problem analyzing part with SRS.

[05 + 02 marks]

Answer:

REQUIREMENT ANALYSIS

Requirements describe the “what” of system not the “how”. Requirements analysis phase of SDLC produces one large
document, written in a natural language. Requirements play an essential role in the software engineering life cycle. One
of the most difficult aspects of program development is in getting both the customers and the developers to understand
what is of them is trying to say. The problems get even more complicated when the user himself does not know the
needs and requirements of the system. Many software projects have failed due to certain requirements engineering
issues such as poorly documented requirements or requirements that are impossible to satisfy.

The identified user requirements are usually informal. The requirement phase translates these informal inputs from the
users into a set of formal specified requirements. The process of requirement analysis helps to bridge the
communication gap between the customer and the developer.

Page 7 of 24
The requirements analysis phase of SDLC consists of three different activities:

 Request clarification

 Feasibility study

 Request approval

Analysis phase is conducted by system analyst. During this phase, the analyst thoroughly studies the organization’s
current procedures and the information systems used to perform organizational tasks.

The goal of the requirements analysis phase is to clearly understand the customer requirements and to systematically
organize these requirements into a specification document called software requirements specification (SRS).

Requirements analysis involves number of suggestions such as:

 Understanding the problem

 Record the origin of and the reason for every requirement

 Use multiple views of requirements

 Set the priority of requirements

 Try to eliminate ambiguity

 Reduce the complexities

Analyst should consider the above suggestions for good quality requirement analysis. Analyst collects detailed
information regarding the project.

USER AND SYSTEM REQUIREMENTS

User requirements are written for the users and include functional and non-functional requirements. Users may not be
experts of the software field; hence simple language should be used. The software terminologies, notification etc.
should be avoided. User requirements should specify the external behavior of the system with some constraints and
quality parameters. However, design issues should be avoided. Hence, we should only highlight the overview of the
system without design characteristics. System requirements are derived from user requirements. They are expanded
form of user requirements. They may be used as input to the designers for the preparation of software design
document. The user and system requirements are the parts of software requirements and specification (SRS) document.
There are various ways of writing these requirements.

SOFTWARE REQUIREMENTS SPECIFICATION

A specification document is prepared by system analyst for the reference, this document is called SRS document. The
SRS is a specification for a particular software product, program or set of programs that perform certain functions in a
specific environment. SRS could be written by developer of the system after a detailed customer communication. This
document reduces the probability of the customer being disappointed with the final product.

CHARACTERISTICS OF A GOOD SRS

Page 8 of 24
The SRS should be:

 It should be correct

 It should be unambiguous

 It should be complete

 It should be consistent

 It should be easy to change

 It should be traceable

 It should serve as a reference tool for system support.

Question Three:

(a) Write the name of various software life cycle models. Explain the prototype model. Under what circumstances is it
beneficial to construct a prototype model? [1.5 + 4.5 + 01 Marks]

Answer:

Name of Software Model:

Build and fix model, waterfall model, Prototype model, iterative enhancement model, spiral model, rapid application
development model and incremental model.

PROTOTYPING MODEL

A disadvantage of waterfall model is that the working software is not available until late in the process, thus delaying the
discovery of serious errors. An alternative to this is to first develop a working prototype of the software instead of
developing the actual software. The working prototype is developed as per current available requirements.

The developers use this prototype to refine the requirements and prepare the final specification document. Because the
working prototype has been evaluated by the customer, it is reasonable to expect that the resulting specification
document will be correct. When the prototype is created, it is reviewed by the customer. Typically this review gives
feedback to the developers that help to remove uncertainties in the requirements of the software.

Fig:

The prototype may be a usable program, but is not suitable as the final software product. The reason may be poor
performance, maintainability or overall quality. The code for the prototype is thrown away; however the experience
gathered from developing the prototype helps in developing the actual system.

After the finalization of software requirement and specification (SRS) document, the prototype is discarded and actual
system is then developed using the waterfall approach.

(b) Briefly discuss the following: [2 X 3.5 Marks]

Page 9 of 24
 iii. Conceptual Design and Technical Design
iv. Module Coupling and Module Cohension

Answer:

CONCEPTUAL AND TECHNICAL DESIGNS

The process of software design involves the transformation of ideas into detailed implementation descriptions, with the
goal of satisfying the software requirements. To transform requirements into a working system, designers must satisfy
both customers and the system builders (coding persons). The customers understand what the system is to do. At the
same time, the system builders must understand how the system is to work. For this reason, design is really a two part,
iterative process. First, we produce conceptual design that tells the customer exactly what the system will do. Once the
customer approves the conceptual design, we translate the conceptual design into a much more detailed document, the
technical design that allows system builders to understand the actual hardware and software needed to solve the
customer’s problem.

The two design documents describe the same system, but in different ways because of the different audiences for the
documents. The conceptual design answers the following questions:

 Where will the data come from?

 What will happen to the data in the system?

 How will the system look the users?

 What is the timing of events?

 How will the reports and screens look like?

To conceptual design describes the system in language understandable to customer.

By contrast, the technical design describes the hardware configuration, the software needs, the communications
interfaces, the input and output of the system, the network architecture, and anything else that translates the
requirements into a solution to the customer’s problems.

MODULE COUPLING

Coupling is the measure of the degree of interdependence between modules. Two modules with high coupling are
strongly interconnected and thus, dependent on each other. Two modules with low coupling are not dependent on one
another. ”Loosely coupled” systems are made up of modules which are relatively independent. “Highly coupled”
systems share a great deal of dependence between modules. For example, if modules make use of shared global
variables. ‘Uncoupled’ modules have no interconnections at all; they are completely independent as shown in figure.

A good design will have low coupling. Thus, interfaces should be carefully specified in order to keep low value of
coupling.

Coupling is measured by the number of interconnections between modules. For example, coupling increases as the
number of calls between modules increases, or the amount of shared data increases. The hypothesis is that design with

Page 10 of 24
high coupling will have more errors. Loose coupling, on the other hand, minimizes the interdependence amongst
modules.

TYPES OF COUPLING:

Different types of coupling are content, common, external, control, stamp and data. The strength of coupling from
lowest coupling (best) to highest coupling (worst) is given in figure.

Data coupling Best

Stamp coupling

Control coupling

External coupling

Common coupling

Content coupling (Worst)

The types of module coupling

MODULE COHESION

Cohesion is the measure of functional relatedness elements within a single module. When dividing a system into
modules, it must be ensured that the activities within module are tightly bound to one another, it can be viewed as
opposite of coupling- in coupling we wanted each module to be independent and interact with other modules with the
least coupling. However, we want all activities within module to be as tightly connected to each other as possible i.e.,
cohesion must be as high as possible. The degree of coupling and cohesion between various modules is a measure of the
quality of the design of the system. The levels of cohesion go from good to bad i.e., the first form of cohesion is the best
form of cohesion and the last form of cohesion is the worst form of cohesion.

The primary characteristics of clean decomposition are high cohesion and low coupling. A module having high cohesion
and low coupling is said to be functionally independent of other modules. In functionally independent module we have
various advantages such as module reusability, reducing the complexity of the design and reducing the errors.

Thus, we want to maximize the interaction within a module. Hence, an important design objective is to maximize the
module cohesion and minimize the module coupling. Cohesion may be viewed as glue that keeps the module together.

TYPES OF COHESION

High Low

Page 11 of 24
 Functional Sequential Communicational Procedural Temporal Logical coincidental

Functional cohesion Best

Sequential cohesion

Communicational cohesion

Procedural cohesion

Temporal cohesion

Logical cohesion

Coincidental cohesion (Worst)

Types of module cohesion

Question Four:
(a): Describe the role of management in software development with the help of example. [06 Marks]
Answer:

The management of software development is heavily dependent on four factors: people, product, process, and
project. Order of dependency is as shown in Fig. 1.8.

Dependency
4 Order
2

Fig. 1.8 Factors of Management dependency (From people to project)

Software development is a people centric activity. Hence, success of the project is on the shoulder of the people
who are involved in the development.

The People

Page 12 of 24
Software development requires good managers. The managers, who can understand the psychology of people
and provide good leadership, A good manager cannot ensure the success of the project, but can increase the
probability of success. The areas to be given priority are; proper selection, training, compensation, career
development, work culture etc.

A manager faces challenges. It requires mental the toughness to endure inner pain. We need to plan for the best,
be prepared for the worst, expect surprises, but continues to move forward anyway. Charles Maurice once rightly
said “I am more afraid of an army of one hundred sheep led by a lion than an army of one hundred lions led a
sheep”.

Hence, manager selection is most crucial and critical. After having a good manager, project is in safe hands. It is
the responsibility of a manager to motivate, encourage, guide and control the people of his/her team.

The Product

What do we want to deliver to the customer? Obviously, a product; a solution to his/her problems.

Hence, Objectives and scope of work should be defined clearly to understand the requirements. Alternative
solution should be discussed. It may help the managers to select a “best” approach within constraints imposed by
delivery deadlines, budgetary restrictions, personnel availability, technical, technical interfaces etc. without well
defined requirements, it may be impossible to define reasonable estimates of the cost, development time and
schedule for the project.

The Process

The process is the way in which we produce software. It provides the framework from which a comprehensive
plan for software development can be established. If the process is weak, the end product will undoubtedly
suffer. There are many life cycle models and process improvement models. Depending on the type of project, a
suitable model is to be selected. Now –a –days CMM (Capability Maturity Model) has become almost a standard
for process framework. The process priority is after people and product, however, it plays very critical role for the
success of the project. A small number of framework activities are applicable to all software projects, regardless
of their size and complexity. A number of different task sets, tasks, milestones, work products, and quality
assurance points, enable the framework activities to be adapted to characteristics of the project and the
requirement of the project team.

The Project

Page 13 of 24
 A proper planning is required to monitor the status of development and to control the complexity. Most of the
projects are coming late with cost overruns of more than 100%. In order to manage a successful project, we must
understand what can go wrong and how to do it right. We should define concrete requirements (although very
difficult) and freeze these requirements. Changes should not be incorporated to avoid software surprises.
Software surprises are always risky and we should minimize them. We should have a planning mechanism to give
warning before the occurrence of any surprise.

All four factors (People, Product, Process and Project) are important for the success of the project. Their relative
importance helps us to organize development activities in more scientific and professional way.

Software engineering has become very important discipline of study, practice and research. All are working hard
to minimize the problems and meet the objective of developing good quality maintainable software that is
delivered on time, within budget, and also satisfies the requirements. With all cries and dissatisfaction, discipline
is improving and maturity day by day. New solutions are being provided in the niche areas and encouraging
results are being observed. We do feel that within couple of years, situation is bound to improve and software
engineering shall be a stable and mature discipline.

(b) Briefly discuss the following:

i. Test case design [02 Marks]
ii. White-box and Black-box Testing [03 Marks]
iii. Alpha, Beta and Acceptance Testing [03 Marks]
Answer:

TEST CASE DESIGN

There are two aspects of test case selection specifying a criterion for evaluating a set of test cases, and generating a set
of test cases that satisfy a given criterion. Often, a criterion is specified and the tester has to generate test cases that
satisfy the criterion. In some cases, guidelines are available for deciding test cases. Overall, the problem of test case
selection is very challenging.

There are two fundamental properties for a testing criterion: reliability and validity. A criterion is reliable if all the sets
that satisfy the criterion detect the same errors. A criterion is valid, if for any error in the program, there is some set
satisfying the criterion that will reveal the error.

Over the past three decades, a rich variety of test case design methods have evolves for software. These methods
provide the developer with a systematic approach to testing.

Black –box Testing

Black box testing or Functional testing refers to testing which involves only observation of the output for certain input
values and there is no attempt to analyse the code, which produces the output. The internal structure of the program is
ignored. For this reason, functional testing is sometimes referred to as a black box testing in which the content of black
box is not known and function of black box is understood completely in terms of its inputs and outputs. Many times we
operate more effectively with black box knowledge. The system is a black box whose behavior can only be determined
Page 14 of 24
by studying its inputs and the related outputs. It is called functional testing because the tester is only concerned with the
functionality and not the implementation of the software. The tester presents inputs to the component or the system
and examines the corresponding outputs. If the outputs are not those predicted, then the test has successfully detected
a problem with the software.

Input domain

Output domain
System Output test
under test data

Input test data

Black box testing

White box Testing

A complementary approach to functional or black box testing is called structural or white box testing. In this approach,
test group must have complete knowledge about the internal structure of the software. It is concerned with testing the
implementation of the program. The intent of structural testing is not to exercise all the different input or output
conditions but to exercise the different programming structures and data structures used in the program.

We can say structural testing is an approach to testing where the tests are derived from knowledge of the software’s
structure and implementation. As the name implies, the tester can analyze the code and use knowledge about structure
of a component to derive test data. The analysis of the code can be used to find out how many cases are needed to
guarantee that all of the statements in the program are executed at least one during the testing process. It would not be
advisable to release software which contained untested statements and the consequence of which might be disastrous.

In functional testing, all specifications are being checked against the implementation, so why do we really require
structural testing? It seems to be necessary because there might be parts of the code, which are not fully exercised by
the functional tests. There may also be sections of the code, which are surplus to requirements.

ALPHA AND BETA TESTING

The terms alpha and beta testing are used when the software is developed as a product for anonymous customers.
Hence formal acceptance testing is not possible in such cases. However, some potential customers are identified to get
their views about the product. The alpha tests are conducted at the developer’s site by a customer. These tests are
conducted in the controlled environment. Alpha testing may be started when formal testing process is near completion.

The beta tests are conducted by the customers/end users at their sites. Unlike alpha testing, developer is not present
here. Beta testing is conducted in a real environment that cannot be controlled by the developer. Customers are
expected to report failures, if any, to the company. After receiving such failure reports, developers modify the code and
fix the bug and prepare the product for final release.

ACCEPTANCE TESTING
Page 15 of 24
This term is used when the software is developed for a specific customer. A series of tests are conducted to enable the
customer to validate all requirements. These tests are conducted by the end user/customer. Acceptance testing may be
conducted for few weeks or months. The discovered errors will be fixed and better quality software will be delivered to
the customer.

Question Five:

(a) What is coding style? Describe the various programming style for good coding of a program.
[02 + 04 Marks]

Answer:

The goal of the coding or programming phase is to translate the design of the system produced during the design phase
into code in a given programming language, which can be executed by a computer and that performs the computation
specified by the design. For a given design, the aim is to implement in the best possible manner.

The coding phase affects both testing and maintenance profoundly. The time spent in coding is a small percentage of the
total software cost, while testing and maintenance consume the major percentage. Thus, it should be clear that the goal
during coding should not be to reduce the implementation cost, but the goal should be to reduce the cost of later phase.
In the other words, the goal during this phase is not to simplify the job of the programmer. Rather, the goal should be to
simplify the job of the tester and maintainer.

This distinction is important, as most programmers are individualistic, and mostly concerned about how to finish their
job quickly, without keeping the later phases in mind. During implementation, it should be kept in mind that the
programs should not be constructed so that they are easy to write, but so that they are easy to read the later phases.
Often, making a program more readable will require extra work by the programmers.

PROGRAMMING STYLE

A good programming style is characterized by the following:

 Simplicity

 Readability

 Good documentation

 Predictability

 Consistency in input and output

 Module independence

 Good structure

During coding of a program, some general rules are also applied which are:

Names: Selecting module and variable names is often, not considered important by novice programmers. Only when
one starts reading programs written by others, where the variable names are cryptic and not representative, does one
realize the importance of selecting proper names. Variable names should be closely related to the entity they represent
and module names should reflect their activity.
Page 16 of 24
Control Constructs: It is desirable that as much as possible, single-entry, single exit constructs be used. It is also
desirable to use a few standard control constructs rather than using a wide variety of constructs, just because they are
available in the language.

Gotos: Gotos should be used sparingly and in disciplined manner. Only when the alternative to using gotos is more
complex, should the gotos be used. In any case, alternative must be thought of, before finally using a goto.

Information hiding: Information hiding should be supported where possible. Only the access functions for the data
structure should be made visible while the hiding the data structure behind these functions.

User defined types: Modern languages allow users to define types like the enumerated type. When such facilities are
available, they should be exploited where applicable.

Module Size: A programmer should carefully examine any routine with very few statements or with too many
statements. There can be no hard and fast rule about module size, the guiding principle should be cohesion and
coupling.

Module interface: A module with a complex interface should be carefully examined. Such modules might not be
functionally cohesive and might be implementing multiple functions.

Program layout: How the program is organized and presented can have great effect on the readability on it. Proper
indentation, blank spaces and parentheses should be used to enhance the readability of programs.

Side effects: When a module is invoked, it some has side effect of modifying the program state beyond the modification
of parameter listed in the module interface definition, for example, modifying global variables.

Defensive Programming: Defensive programming does not mean being defensive about your programming. The idea is
based on defensive driving, in which you adopt the mind-set that you’re never sure what the other drivers are going to
do. That way, you make sure that if they do something even dangerous, you won’t be hurt. In defensive programming
the main idea is that if a routine has passed bad data, it won’t hurt, even if the bad data is another routine’s fault.
Defensive programming is useful as an addition to the other techniques for quality improvement.

(b) List the name of common risks that encounter in most software project and explain any two of them.
[01+ 04 Marks]

Answer:

RISK ANALYSIS

Some of the common risks encountered in most software projects.

a) Manpower risks

b) Technology risk

c) Customer/User risk

d) Environment risk

Manpower risks: Manpower risk relates to attraction of people leaving the project when the project is still in the
development stage. This can cause substantial delays as new people may have to be recruited and trained which could
Page 17 of 24
lead to delays in project deliverables. The change in personnel could also lead to re-doing some work as the person may
want to start things afresh rather than take over the previous person’s work and continue from there. The impact on the
project is more severe if one of the senior members of the project suddenly leaves the project as the new person might
want to make changes with higher impact on schedules and deliverables.

This risk can be addressed by either having a strong process driven organization or overstaffing the project to cater to
such contingencies. As organization cannot be converted into a process driver organization overnight. It will have to be
along term strategy of the organization. A process driven organization will not feel the impact of the charge in personal
as processes, by their very definition one supposed to be people independent. Thus, changes in poisoned can be
handled without major impact in organization with strong processes. In the field of software, there are very few
organizations with such a degree of process orientation.

Another way of addressing the risk and more common way is overstuffing. This will have cost impact but the impact on
schedules may be minimized. At the senior level (Project manager/ Team leader) it might be prudent to have a backup
person for critical positions so that change in personnel is mitigated. For development personnel, it might suffice to have
a pool of people who might be assigned to a low priority project and can be pulled into the critical project at short
notice. This will help reduce costs as the poll could be common across many projects.

Technology risk: We know that the self of various technologies is between six months to two years in a rapidly changing
world. There are two kinds of risks related to technology.

1. Using new technology

2. Using outdated technology

Both technologies have the own set of risks.

If we are using new technology, the major risks are availability of manpower with skills in that area and stability of
the product itself. These can be countered with effective training and a good acceptance test on the product but
mere class room training may not be sufficient for person to person to program effectively using a new tool. In such
case, a buffer period for person to play around with the tool and try out its features, develop standards for using the
tool must be provided in the project schedule.

If we are an outdated tool, the risk is manpower retention as people always want to work on the latest technology.
They will want to move to organization which is using the latest technology. This risk has to be addressed as
described under manpower risk and clean directive of the organization’s plans to move to the latest version of the
tool.

Another related risk is that the project starts on the latest technology but by the end of the project a new version of
technology has come into market and the project is implemented with ’absolute’ technology. The best decision
under the circumstances is to go ahead and implement the software with the older version of the tools. After
successful implementation and stabilization of the product a new project can be initiated to convert the software
from the older version to the current version.

(c) What do you understand by project cost estimates? [02 Marks]

Page 18 of 24
Answer:

A typical software project comprises of the following expense heads:

 Manpower cost

 Hardware cost

 Software cost

 Travel cost

 Training cost

 Administration cost

Question Six:

(a) Define the software maintenance. Also, discus the problem associated with software maintenance.
/ [02 + 05 Marks]

Answer:

SOFTWARE MAINTENANCE

Software maintenance is the process of changing a system after it has been delivered to the customer. Maintenance is
inevitable for almost any kind of product. Most products need maintenance due to wear and tear by use. We know that
software products do not need maintenance on this count, but software products required maintenance on account of
the following main reasons:

1. Corrective maintenance

2. Adaptive maintenance

3. Perfective maintenance

4. Preventive maintenance

PROBLEMS DURING MAINTENANCE

The very important problem during maintenance is that before modifying or correcting a program, the parameter must
understand it.

Few problems are discussed below:

1. Sometimes the program is written by another person or group of persons working over the years in isolation
from each other.

2. Sometimes the program is changed by person who did not clearly understand

Page 19 of 24
 3. Some problems only become clear when a system is in use. Many users know what they want but lack to ability
to express it in a form understandable to programmers or analysts. This is primarily due to information gap.

4. Systems are not designed for change. If there is hardly any scope for change maintenance will be very difficult.

5. There is high staff turnover within information technology industry. Due to this many systems are maintained by
persons who are not original authors. These persons may not have adequate knowledge about the system. This
means that this person may introduce changes to programs without being aware of their effects on other parts
of the system-the ripple effect. This problem may be worsened by the absence of documentation.

All these problems translate to a huge maintenance expenditure, which has been estimated ranging from 40% to 70% of
the total cost during the life cycle of large scale software systems.

(b) What is software quality? Describe the software quality factors proposed by Mc-Call. [02 + 05 Marks]

Answer:

SOFTWARE QUALITY

To assure the quality one has to ensure the quality. To ensure the quality it is necessary to make systematic controls at
every stage and also to take critical review of efforts and achievements of the company with respect to quality of the
product. For making systematic controls, co-operation of every employee is needed, since quality depends on every
person working in the organization. Every employee’s involvement is the most important in the understanding the
problems, finding solution and implementing them. All these action would lead to maintain and improve quality and
reliability of the product. The software developer can assure the quality of the software product and can guarantee its
performance with full confidence. Second quality assurance system thus helps to maintain/improve the quantity of the
products and hence the reputation of the firm and better customer relations.

Basically, a quality product is defined in terms of its fitness of purpose that means a quality product does not exactly
what the users want it to do. For software products, fitness of purpose is usually interpreted in terms of satisfaction of
the requirements laid down in the SRS document.

To achieve high-quality software is now the objective of most organization. It is no longer acceptable to deliver poor
quality products and the repair problems and deficiencies after they have been delivered to the customer. Software
quality assurance (SQA) is an umbrella activity that is applied throughout the software engineering process.

McCall and his colleagues have proposed a number of software quality factors that affect software quality.

1. Correctness: The extent to which a program satisfies its specification and fulfills the customer in main objectives.

2. Reliability: The extent to which a program can be expected to perform its intended function with required precision.

3. Efficiency: The amount of computing resources and codes required by a program to perform its function.

4. Integrity: The extent to which access to software or data by unauthorized person can be controlled.

5. Usability: The effort required to learn operate, prepare input, and interpret output of a program.

6. Maintainability: The effort required to locate and fury an error in a program.

7. Flexibility: The effort required for modifying an operational program.

Page 20 of 24
8. Testability: The effort required for testing a program to ensure that it performs its intended function.

9. Probability: The effort required for transferring the program from one hardware and/or software system
environment to another’s.

10. Reusability: The extent to which a program can be reused in the other applications.

11. Interoperability: The effort required to couple one system to another.

The grading scheme proposed by McCall is 0 to 10 scale.

Question Seven:

(a) Discuss the CASE tools? How does CASE support in software life cycle? [07 Marks]

Answer:

The best workshop for any craftsperson-a machine, a carpenter or a software engineer-has three primary
characteristics:

1) A collection of useful tools that will help in every step of building a product.

2) An organized layout that enables tools to be found quickly and used efficiently.

3) A skilled craftsman who understands how to use the tools in an effective manner.

Software engineers now recognize that they need more and varied tools and they need an organized and efficient
workshop in which to place the tools.

CASE stands for Computer Aided Software Engineering, CASE is a tool which aids software engineer to maintain and
develop software. The workshop for software engineering is called an integrated project support environment and the
tool set that fills the workshop is called computer aided software engineering. CASE tools add to the software engineer’s
tool box. CASE provides the engineer with the ability to automate manual activities and to improve engineering insight.

A CASE tool enables people working on a software project to store data about a project-its plan and schedules to be able
to track its progress and make changes easily, analyze and store data about user requirements, store the design of n
system-all through automation.

Software engineering is all about automating an application. CASE is about automating those software engineering
processes that aid in automation of applications. Use of tools is not new to the software engineering process. We have
the data flow diagram as a process analysis tool, the ERD as a data analysis tool, the structure chart as a design tool.
When we mention a CASE tool today, we necessarily mean an automated version of tools that is an automated data flow
diagram, ERD and the system chart plus synchronization of data across tools of all phases of the systems development
life cycle.

Computer aided software engineering can be as simple as a single tool that supports a specific software engineering
activity or as complex as a complete environment that encompasses tools, a database, people, hardware, a network,
operating systems and other components. CASE technology has come a large way since its inception in the early 1980s

Page 21 of 24
when all it had to offer was a set a standalone drawing tools. Today a wide range of case tools is available in the market.
Different type of case tools addresses different areas of software engineering. CASE tool technology can be split into
three levels. These levels are:

 Production-process support technology

 Process management technology

 Meta case technology

Production-process support technology: This range of tools supports process activities such as specification, design,
implementation and testing.

Process management technology: This range of tools supports process modeling and process management. This range
of tolls will interact with, ‘production-process’ support tools for specific process activities.

Meta case technology: These tools are used to create production process and process management support tools. Some
tools are available but they haven’t been widely adopted by the industry due to the fact that they are difficult to use.

The building blocks for CASE are illustrated in the following figure. Each building block forms a foundation for the next
with tools sitting at the top of the heap.

CASE Tools
Integration Frame
Work
Portability Services
Operating System
Hardware Platform
Environment Architecture

The environment architecture, composed of the hardware platform and operating system support including networking
and database management software, lays the ground work for case. A set of portability services provides a bridge
between CASE tools and their integration framework and the environment architecture.

The integration framework is a collection of specialized programs that enables individual CASE tools to communicate
with one another to create a project database and to exhibit the same look and feel to the end user. Portability services
allow CASE tools and their integration framework to migrate across different hardware platforms and operating systems
without significant adaptive maintenance.

(b) What are different types certifications? Explain the significant of each type and which one is most important for the
end user? [07 Marks]

Answer:

Page 22 of 24
TYPES OF CERTIFICATION

As discussed earlier, there are three categories of certifications available in the field and related persons, processes and
products. The first two (i.e., persons and processes) are industry specific and customer may not be directly interested.
However, third one (i.e., product) is directly for the customer and helps to select a particular product.

Certification of persons

In general, Certification is employees initiated improvement process which improves competencies in quality assurance
methods and techniques. Software industry is becoming more and more competitive day by day and forces the
management to distinguish professional and skilled individuals in the field. Certification demonstrates a level of
understanding in carrying out quality assurance principles and practices. Acquiring the designation of certified software
quality analyst (CSQA), certified software tester (CSTE) or certified software project manager (CSPM) indicates a
professional level of competence in the principles and practices of software quality assurance in the software industry.
These certification gain recognition as software quality professional, facilitate more rapid career advancement, and gain
greater acceptance in the role as advisor to management.

Some company specific certifications are very popular like Microsoft Office Specialist (MOS) certifications in word, excel
and power point. Many people are doing it to validate that they have a good working knowledge of office software used
by approximately 95% of the world’s business community. MOS is by far the best known computer skills certification for
administration. Many other companies are also offering certifications for their products like CISCO, SUN etc.

Certification of Processes

The most popular process certification approaches are ISO-9000 and SEI-CMM. Both the approaches have certified levels
and higher levels give high confidence to customer about the software development practices and processes. Whenever
we deal with a CMM leel-5 company unconsciously we are confident about the quality of its product, though this may
prove to be an illusion because dirty water can also run from clean pipes. Hence, we should always be suspicious about
the quality of end product. However, certification reduces the possibility of poor quality products. We may go for any
type of process certification, it help us to produce good quality and stable software product.

Certification of Products

This is what is required for the customer. Although, it is also dependent on first two categories of certifications, but this
is ultimate indicator of quality and trust for the customer. there is no universally accepted product certification scheme.
However, aviation industry has a popular aircraft certification “RTCADO-178B” which has become a defacto standard:
this is produced by Radio Technical Commission for Aeronautics (RTCA) as the accepted means of certifying all new
aviation software. The targeted DO-178 B certification level is either A, B, C, D or E. These levels describe the
consequences of a potential failure of the software: catastrophic, hazardous-severe, major, minor or no effect. The
following documents and records are required for this certification:

(a) DO-178 B Documents

i. Software Development Plan
ii. Software Verification Plan
iii. Software Configuration Management Plan
iv. Software Quality Assurance Plan
v. Software Requirements Standards
vi. Software Design Document

Page 23 of 24
 vii. Software Verification Test Cases and Procedures
(b) DO-178 B Records
i. Software Verification Results
ii. Problem Reports
iii. Software Configuration Management Records
iv. Software Quality Assurance Records

The DO-178 B Certification process is most demanding at higher levels. A product certified to DO-178 B level A would
have the largest potential market, but it would require through labour intensive preparation of most of the items on the
DO-178 B support list. Conversely, a product certifying to DO-178 B level E would require fewer support items and be
less taxing on company resources.

We do not have product certification standards in most of the areas. RTOS (Real Time Operating System) is the real time
operating system certification and market as “Lynx OS 178” which is based on open standards. The establishment of
independent agencies for product certification may be the viable option. This will only be successful if such agencies are
willing to share responsibility of failures. We can expect good number of such agencies with their certification guidelines
and standards in coming years. This will not only help the customer but also the software industries and the atmosphere
of mistrust may be reduced if not completely wiped out.

THIRD PARTY CERTIFICATION FOR COMPONENT BASED SOFTWARE ENGINEERING

Component based software engineering may become popular if we develop standards for certification. These standards
should be measurable, verifiable and either establishes that a product meets the performance specifications or fail in
some way to meet the design. Many visible engineering failures result in the call for a third-party certification
organization to ensure the welfare of the general public. The software has caused the failures of many business, delayed
important business plans, and made shareholders and the public lose millions of dollars per year because of poor
management techniques.

Some standards are to be adopted by everyone, whether bolt manufactures or software component producers.
Compliance with standards is much easier. Contractor gives the standard, directs any variations in the specifications,
defines patterns and permissible tolerances and also fixes the date of delivery. Contractor may subcontract some of the
duties with given standards. However, bolts will have to contend with various forces, such as: high winds, cold weather,
warm weather, shifting sand and silt against the truss or stress the girder.

Third party certification is a method to ensure software components conform to well defined standards. Based on this
certification, trusted assemblies of components can be constructed. The producer and consumer will require third party
certification to establish confidence in the software components. Third party certification for software components is
based on UL 1998, 2nd ed., UL standard for safety for software in programmable components [TRAC 0]. UL has also
announced that it will expand UL/1998 possibly beyond safety critical components and has formed a new ANSI/UL
planning panel for that purpose, as well as to upgrade the existing standard.

Page 24 of 24