Introduction to Software Engineering

Introduction

Software engineering not only deals with how software should be used to solve problems
but also important aspects such as analysis, design, debugging, testing and
documentation. These are essential as users now expect continued support; but the
systems have also gotten so complex that there is no other method to make projects more
manageable. Software engineers adopt a systematic and organized approach to their
work in order to effectively produce high quality software.

When looking at the users of a system one need to look at the users of the software
whether at the organization or the individual level. Software and information systems are
increasingly becoming a part of the organizational landscape and as such more and more
employees are required to become computer literate. As such organizations have become
more and more dependent on these information systems.

Why use Software Engineering?

There have been many examples of software projects failing to achieve objectives or
plain failing to produce any software at all. Some reasons for this are as follows:
increasing costs of software development; dissatisfaction of users and management with
quality and suitability; and the increasing length and complexity of software.

Increasing Costs

It is now costing more to pay someone to write software. This is especially so because
the more computer literate a workforce is the more they expect. Thus the daunting task
of distinguishing between user needs and wants (to be discussed later).
Costs
- size of development team
-costs of acquiring development tools: compilers, design tools
- computers (servers)
- peripherals
- networking tools
- groupware
- overruns because deadlines not met
- downtime or less productivity during analysis (meeting with users),
implementation, training of staff.
- marketing or dissemination of information about the new system
Dissatisfaction of Users and Management

Requirements may not have been properly defined. Miscommunication between users
and software developers. Software may be obsolete upon completion.
Users
Requirement: want or need; required condition
Responsibility: role in the organization; how they will interact with the system.
Desires:
Behaviour: affects security and stability influence organizational policies; access to
internet and other resources;; how information is managed, accessed and stored;
password policies; locking computers when not in use.

Length and Complexity of Software

Increases needs for software. Compatibility issues with other software or systems. User
requirements have changed or increased. Users require more graphical interfaces.
Software increasingly needs to be network or internet enabled. You need to ensure it is
compatible with certain category or specification of hardware (e.g. memory, processor).

Requirements for standard interfaces

Interfaces are important as in most instances software systems must operate with other
systems that have already been implemented and installed in the environment. As such
the interfaces must be precisely defined. It is essential that these specifications be
defined early in the process such as in the requirements document. Three examples are:
procedural interfaces; data structures and the representation of data.

Procedural Interfaces
These must be considered where there are subsystems or services that are accessed by
calling interface procedures.

Data Structures
Data structures may be passed from one subsystem to another. It is essential that the
receiving subsystem receives what it is expecting or else incompatibility issues will arise.

Representation of Data.
Representation of data may go down to the bit level. Firstly however one must ensure
that procedures, modules and subsystems are using the same data type and the same data
size. It may also go down to the way in which bits are ordered.

Need for tighter control and management of process

This is usually achieved by using project management and assigning a project or software
manager to the team. Management activities include: proposal writing, project planning
and scheduling; project costing; project monitoring and reviews; personnel selection and
evaluation; and report writing and presentations.

Proposal Writing
This describes the objective of the project and how it will be carried out. It normally
includes cost and schedule estimates and may justify why a project contract should be
awarded to a particular organization or team.

Project Planning and Scheduling

Planning involves identifying the activities, milestones and deliverables produced by a
project. A plan must be drawn up to guide the development towards the project goals.

Project Costing
This is related to planning in which you estimate the resources (people, equipment, and
materials) required to accomplish the project plan.

Project Monitoring and Reviews

This is a continuing project activity through which a manager keeps track of the progress
of the project. It involves comparing actual and planned project and costs. This is
essential to ensure the project is on time and within the budget. Informal monitoring is
also important in order to detect early any problems that may arise. This may be though
daily discussions with project staff. Formal meetings may also be arranged where the
entire team come together to discuss the project. These would allow the manager to
assign additional resources and reallocate resources in order to prevent schedule slippage
or to accommodate tasks or issues not identified in the initial plan.

Personnel Selection and Evaluation

Ideally skilled staff with appropriate experience will be available to work on the project.
However in reality managers will have to settle for a less than ideal time. This may be
because: the budget cannot cover the use of highly paid, experienced staff. Staff with
appropriate experience is not available as they may be on other projects or it is not
possible to recruit new staff to the project. The organization may wish to develop the
skills of its employees so they are assigned to the project to learn and gain new skills.

However it is best to ensure that at least team member has experience in this type of
project in order to avoid many problems.

Report Writing and Presentations

The manager is usually responsible for reporting on the project to the client or contractor
organization. He/ she must write concise, coherent documents that extracts critical
information from detailed project reports. They must be able to present this information
during progress reviews. As a result the ability to communicate effectively both orally
and in writing is an essential skill of a project manager.
Visibility of the process

The visibility of the process is first achieved through the project plan. The manager start
off with the best possible plan given the available information. This plan evolves as the
project progresses and better information becomes available. Apart from the project plan
there are other plans that may need to be put into place: quality plan; validation plan
(includes test plan); configuration management plan; maintenance plan and staff
development plans.

Types of Plans

Quality plans describe the quality procedures and standards that will be used in the
project. Quality management provides (ideally) an independent check on the software
development process. These can be structured as follows: quality assurance; quality
planning; and quality control. Quality assurance involves the establishment of
organizational procedures and standards which lead to high quality software. This
encompass both the product and the process. An example of an international standard is
the ISO 9000. Quality planning involves the selection of appropriate procedures and
standards from the quality assurance framework and adapting them to a specific software
project. This involves describing the product, plan, process, quality goals and identifying
risks and ways to manage them. Quality control provides the definition and enactment of
processes which ensure that the project quality procedures and standards are followed by
the software development team. This may include quality reviews and automated
software assessment. The deliverables from the software process act as input to the
quality management process. Ideally this should be done by an independent team or
person who is not influenced by the management responsibilities such as budgets and
schedules. They would thus be able to view the project objectively and report problems
to senior management or the client.

Validation plan describes the approaches, resources, and schedules used for system
validation. This is the checking and analysis done to ensure that software conforms to its
specification and meets the needs of the customer. This starts with requirements reviews,
continues with design reviews, code inspections and product testing. Software
inspections involve analyzing and checking system representations such as requirements
documents, design diagrams and the program source code. Software testing involve
executing an implementation of the software with test data and examining the outputs of
the software and its operating behaviour. It also includes defect testing which is intended
to find inconsistencies between the program and its specification. Statistical testing is
used to test the programs performance and reliability, that is under operational conditions.
These tests are designed to reflect actual user inputs and their frequency. After testing an
estimate of the systems reliability can be made by counting the number of observed
system failures. System performance can also be observed by measuring the execution
and response times as it processed statistical test data. A test plan includes the testing
process (major phases); requirements traceability (user interested that requirements are
met); products of the software process to be tested; testing schedule; test recording
procedures (in order to be able to audit the testing process, and is linked to overall project
development schedule); hardware and software requirements; constraints (e.g shortage of
testers).

Configuration plans describes the configuration management procedures and structures to

be used. This type of plan is applicable when managing an evolving system (e.g
incremental development) where different versions of the software are developed. These
versions come to incorporate proposals for change; correction of faults and adaptation for
different hardware and operating systems. An example of an international standard for
configuration management is IEEE 828-1983. These plans may be seen as part of a more
general quality management process. Configuration planning includes defining how to
record and process proposed system change; how to relate these to other system
components; and the methods used to identify different versions of the software.
Configuration management tools may be used to store versions of system components.

Maintenance plans try to predict the maintenance requirements of a system, maintenance

costs and efforts required. These are a necessity once software is put into use as new
requirements emerge and the existing requirements may change. Also parts of software
may need to be modified in order to correct errors found during operation, improve its
performance or other non-functional requirements. Basically after delivery software
must evolve in response to demands for change.

Staff development plans describes how the skills and experience of the project team
members will develop.

Project Plan

The project plan may include all the plans listed above or they may be separate plans and
the project plan makes reference to them. In the case where they are separate plans the
breakdown may be as follows: introduction; project organization; risk analysis; hardware
and software resource requirements; work breakdown; project schedule; and monitoring
and reporting mechanisms. The project plan should be regularly revised and aspects such
as the project schedule will change frequently while other parts become more stable.

Introduction
Briefly describes the objectives of the project as well as constraints such as budgets and
time which may affect the project.

Project Organization
Describes the way in which the development team is organization, the people involved
and their role(s) in the team.
Risk Analysis
This describes possible project risks, the likelihood of these risks arising and the risk
reduction strategies which are proposed (see section on Risk Management).

Hardware and Software resource requirements

Describes the hardware and support software required to carry out the development. If
hardware or software is to be bought, estimates of the prices and delivery schedules
should be included.

Work Breakdown
Breaks down the project into activities and identifies the milestones and deliverables
associated with each activity. Milestones represent the end of a distinct, logical stage of
the project. It is usual to have an accompanying report. Deliverables are tangible
aspects of the project that are delivered to the customers. Deliverables are usually
milestones but milestones are not necessarily deliverables.

Project Schedule
Describes the dependencies between activities; the estimated time required for each
activity and milestone and the allocation of people to the project. When making
estimates unless the current project is similar to previous projects then the estimates will
be optimistic at best even if the manager tries to account for all the eventualities,
especially for technical projects. In some instances the work will be carried out in
parallel. Project scheduling involves coordinating these activities and organizes work so
that the resources, especially workforce is used optimally. Thus reducing the likelihood
that the entire project is delayed because a critical task is unfinished.

As a rule of thumb project activities should normally last a week. Finer subdivisions may
mean that a disproportionate amount of time must be spent on estimating a chart revision.
On the other hand if an activity takes more than eight to ten weeks it may mean that some
further subdivision is needed. Techniques used to represent or make project schedules
include bar (Gantt) charts and activity networks (will be covered later).

Things that may affect your schedule are: individuals falling ill or may leave; hardware
may break down; support software or hardware may be delivered late; or certain parts
may turn out to be more difficult or take longer than anticipated if a project is new or
technically advanced. Also ensure that all needed resources are accounted for such as
space on server; time with specialized hardware (e.g. simulator); or travel budget for
project staff in order to avoid saying “I hadn’t thought off”.

When estimating, do so as if nothing will go wrong, then increase your estimate to cover
anticipated problems. As a further contingency you can then add a further contingency
time o cover unanticipated problems. For examples add to your estimate 30% for
anticipated problems and 20% for unanticipated problems.

Monitoring and Reporting Mechanisms

Describes the management reports that should be generated; when they should be
generated and the project monitoring mechanisms that should be used.

Risk management

Managers must anticipate risks to the project schedule or quality and take actions to avoid
them. A risk is probability that some adverse circumstance will actually occur. There are
project risk, which affect the project schedule or resources; product risk, which affect the
quality or performance of the software being developed; and business risks, which affect
the organizations ability to develop or procure the software. These classifications
however are not exclusive. For example an experienced programmer leaves the project.
It is a project risk as the project may be delayed; a product risk because the replacement
may not be as experienced and as such may make mistakes; and a business risk because
that persons experience is not available for bidding for future business.

Risks are inherent on software projects since stem from loosely defined requirements;
difficulties in estimating times and resources required for software development;
dependence on the individual skills; and requirements changes due to changes in
customer needs. Managers should anticipate risks, understand the impact of these risks
on the project, product, and business; takes steps to avoid these risk. Contingency plans
may be drawn up so that if these risks do occur, identifies immediate recovery action if
possible.

Possible risks with projects are: staff turnover; management change; hardware
unavailability; requirements change; specification delays; size underestimated; CASE
tools underperformance; technology change; and product competition. Staff turnover
may occur when persons leave the project before it is completed. The management may
change and have different priorities. This may result in the change in requirements or
even the cancellation of the project. Hardware may be unavailable that is essential to the
project which may delay the completion of the project. As a part of the planning
contingency time may be allocated for changes in the requirements. However there may
be still be a larger number of changes than were anticipated. These may delay or increase
costs for the project. Delays will also occur when the specification of essential interfaces
are not available time. Another risk may be that the underlying technology used in the
project is superseded by newer technology. A competitive product may be marketed
before your project is completed. Risks may also be classified by technology, people,
organizational, tools, requirements, and estimation.

Risk management encompasses four stages: risk identification. Risk analysis, risk
planning, and risk monitoring. Risk analysis assesses the likelihood and consequences of
risks (the severity of the consequence). Risk planning outlines plans to avoid or
minimizing its effects on the project are drawn up along with contingency plans. Risks
are constantly assessed and the plan for risk mitigation revised as more information is
available. This is however an iterative process.

Need for involvement of end user and management

Discussion Questions
1. Who is an end user?
2. Who is management?
3. Are these groups mutually exclusive?
4. Why do we need to involve the end user in the software development process?
5. Why do we need to involve management in the software development process?