Software Engineering
Software engineering (SE) is concerned with developing and maintaining software systems
that; behave reliably and efficiently, are affordable to develop and maintain, and satisfy all
the requirements that customers have defined for them.
It is important because of the impact of large, expensive software systems and the role of
software in safety-critical applications.
It integrates significant mathematics, computer science and practices whose origins are in
engineering.
Software engineer
A software engineer is a licensed professional engineer who is schooled and skilled in the
application of engineering discipline to the creation of software.
A software engineer is often confused with a programmer, but the two are vastly different
disciplines. While a programmer creates the codes that make a program run, a software
engineer creates the designs the programmer implements.
Software development is the process of computer programming, documenting, testing,
and bug fixing involved in creating and maintaining applications and frameworks resulting
in a software product.
Software development is a process of writing and maintaining the source code, but in a
broader sense, it includes all that is involved between the conception of the desired software
through to the final manifestation of the software, sometimes in a planned
and structured process.
Important Qualities for Software Developers
Analytical skills. Developers must analyze users’ needs and then design software to meet those needs.
Communication skills. Developers must be able to give clear instructions to others working on a project.
They must also explain to their customers how the software works and answer any questions that arise.
Computer skills. Developers must understand computer capabilities and programming languages in order
to design effective software.
Creativity. Developers are the creative minds behind new computer software.
Detail oriented. Developers often work on many parts of an application or system at the same time and
must therefore be able to concentrate and pay attention to detail.
Interpersonal skills. Software developers must be able to work well with others who contribute to
designing, developing, and programming successful software.
Page 1 of 58
Problem-solving skills. Because developers are in charge of software from beginning to end, they must be
able to solve problems that arise throughout the design process.
Software process models
The software process consists of the activities and associated information that are required to
develop a software system. Every organization has its own specific software process but these
individual approaches usually follow some more abstract generic process model.
-
the following are some of the process models
a) SDLC generic model
b) RAD- rapid application development
c) Prototyping
d) Object oriented
e) waterfall
SDLC
System Study
Preliminary system study is the first stage of system development life cycle. This is a brief
investigation of the system under consideration and gives a clear picture of what actually the
physical system is? In practice, the initial system study involves the preparation of a System
proposal which lists the Problem Definition, Objectives of the Study, Terms of reference for
Study, Constraints, Expected benefits of the new system, etc. in the light of the user
requirements. The system proposal is prepared by the System Analyst (who studies the
system) and places it before the user management. The management may accept the proposal
and the cycle proceeds to the next stage. The management may also reject the proposal or
request some modifications in the proposal. In summary, we would say that system study
phase passes through the following steps:
problem identification and project initiation
background analysis
inference or findings
Feasibility Study
In case the system proposal is acceptable to the management, the next phase is to
examine the feasibility of the system.
Page 2 of 58
The feasibility study is basically the test of the proposed system in the light of its
workability, meeting user’s requirements, effective use of resources and of course, the
cost effectiveness.
These are categorized as technical, operational, economic, schedule and social
feasibility.
The main goal of feasibility study is not to solve the problem but to achieve the scope.
In the process of feasibility study, the cost and benefits are estimated with greater
accuracy to find the Return on Investment (ROI).
This also defines the resources needed to complete the detailed investigation. The
result is a feasibility report submitted to the management.
This may be accepted or accepted with modifications or rejected. In short, following
decision are taken in different feasibility study:
Economic feasibility - The likely benefits outweigh the cost of solving the problem which is
generally demonstrated by a cost/ benefit analysis.
Operational feasibility - Whether the problem can be solved in the user’s environment with
existing and proposed system workings?
Organizational feasibility – Whether the proposed system is consistent with the
organization’s strategic objectives?
Technical feasibility - Whether the problem be solved using existing technology and
resources available?
Social feasibility – Whether the problem be solved without causing any social issues?
Whether the system will be acceptable to the society?
Detailed System Study
The detailed investigation of the system is carried out in accordance with the
objectives of the proposed system.
This involves detailed study of various operations performed by a system and their
relationships within and outside the system.
During this process, data are collected on the available files, decision points and
transactions handled by the present system.
Interviews, on-site observation and questionnaire are the tools used for detailed
system study. Using the following steps it becomes easy to draw the exact boundary
of the new system under consideration:
Keeping in view the problems and new requirements
Page 3 of 58
Workout the pros and cons including new areas of the system
All the data and the findings must be documented in the form of detailed data flow
diagrams (DFDs), data dictionary, logical data structures and miniature specifications.
It includes planning for the new system, analysis of requirement, system constraints,
functions and proposed system architecture, prototype of the proposed system and its
analysis.
System Analysis
Systems analysis is a process of collecting factual data, understand the processes
involved, identifying problems and recommending feasible suggestions for improving
the system functioning.
This involves studying the business processes, gathering operational data, understand
the information flow, finding out bottlenecks and evolving solutions for overcoming
the weaknesses of the system so as to achieve the organizational goals. System
Analysis also includes subdividing of complex process involving the entire system,
identification of data store and manual processes.
The major objectives of systems analysis are to find answers for each business
process:
What is being done?
How is it being done?
Who is doing it?
When is he doing it? Why is it being done?
How can it be improved?
It is more of a thinking process and involves the creative skills of the System Analyst.
It attempts to give birth to a new efficient system that satisfies the current needs of the
user and has scope for future growth within the organizational constraints.
The result of this process is a logical system design.
System analysis is an iterative process that continues until a preferred and acceptable
solution emerges.
System Design
Based on the user requirements and the detailed analysis of a new system, the new
system must be designed.
Page 4 of 58
This is the phase of system designing. It is the most crucial phase in the development
of a system.
The logical system design arrived at as a result of system analysis and is converted
into physical system design.
In the design phase the SDLC process continues to move from the what questions of
the analysis phase to the how.
The logical design produced during the analysis is turned into a physical design - a
detailed description of what is needed to solve original problem.
Input, output, databases, forms, codification schemes and processing specifications
are drawn up in detail.
In the design stage, the programming language and the hardware and software
platform in which the new system will run are also decided.
Data structure, control process, equipment source, workload and limitation of the
system, Interface, documentation, training, procedures of using the system, taking
backups and staffing requirement are decided at this stage.
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, Structured English, Decision table and Decision tree which will be
discussed in detailed in the next lesson.
Coding
The system design needs to be implemented to make it a workable system.
This demands the coding of design into computer language, i.e., programming
language.
This is also called the programming phase in which the programmer converts the
program specifications into computer instructions, which we refer to as programs.
It is an important stage where the defined procedures are transformed into control
specifications by the help of a computer language.
The programs coordinate the data movements and control the entire process in a
system.
A well written code reduces the testing and maintenance effort.
It is generally felt that the programs must be modular in nature.
Page 5 of 58
This helps in fast development, maintenance and future changes, if required.
Programming tools like compilers, interpreters and language like c, c++, and java etc.,
are used for coding .with respect to the type of application.
The right programming language should be chosen.
Testing
Before actually implementing the new system into operations, a test run of the system
is done removing all the bugs, if any.
It is an important phase of a successful system.
After codifying the whole programs of the system, a test plan should be developed
and run on a given set of test data.
The output of the test run should match the expected results. Sometimes, system
testing is considered as a part of implementation process.
Using the test data following test run are carried out:
Program test
System test
Program test : When the programs have been coded and compiled and brought to working
conditions, they must be individually tested with the prepared test data. All verification and
validation be checked and any undesirable happening must be noted and debugged (error
corrected).
System Test : After carrying out the program test for each of the programs of the system and
errors removed, then system test is done. At this stage the test is done on actual data. The
complete system is executed on the actual data. At each stage of the execution, the results or
output of the system is analyzed. During the result analysis, it may be found that the outputs
are not matching the expected output of the system. In such case, the errors in the particular
programs are identified and are fixed and further tested for the expected output. All
independent modules be brought together and all the interfaces to be tested between multiple
modules, the whole set of software is tested to establish that all modules work together
correctly as an application or system or package.
When it is ensured that the system is running error-free, the users are called with their own
actual data so that the system could be shown running as per their requirements.
Implementation
After having the user acceptance of the new system developed, the implementation
phase begins.
Page 6 of 58
Implementation is the stage of a project during which theory is turned into practice.
The major steps involved in this phase are:
Acquisition and Installation of Hardware and Software
Conversion
User Training
Documentation
The hardware and the relevant software required for running the system must be made
fully operational before implementation.
The conversion is also one of the most critical and expensive activities in the system
development life cycle.
The data from the old system needs to be converted to operate in the new format of
the new system. The database needs to be setup with security and recovery procedures
fully defined.
During this phase, all the programs of the system are loaded onto the user’s computer.
After loading the system, training of the user starts. Main topics of such type of
training are:
How to execute the package?
How to enter the data?
How to process the data (processing details)?
How to take out the reports?
After the users are trained about the computerized system, working has to shift from
manual to computerized working.
The process is called Changeover. The following strategies are followed for
changeover of the system.
1. Direct Changeover: This is the complete replacement of the old system by the new
system. It is a risky approach and requires comprehensive system testing and training.
2. Parallel run : In parallel run both the systems, i.e., computerized and manual, are
executed simultaneously for certain defined period. The same data is processed by
both the systems. This strategy is less risky but more expensive because of the
following facts:
Manual results can be compared with the results of the computerized system.
The operational work is doubled.
Page 7 of 58
Failure of the computerised system at the early stage does not affect the working of the
organization, because the manual system continues to work, as it used to do.
(iii) Pilot run: In this type of run, the new system is run with the data from one or more of
the previous periods for the whole or part of the system. The results are compared with the
old
system results. It is less expensive and risky than parallel run approach. This strategy builds
the confidence and the errors are traced easily without affecting the operations.
The documentation of the system is also one of the most important activity in the system
development life cycle. This ensures the continuity of the system. Generally following two
types of documentations are prepared for any system.
User or Operator Documentation
System Documentation
User Documentation: The user documentation is a complete description of the system from
the user’s point of view detailing how to use or operate the system. It also includes the major
error messages likely to be encountered by the user.
System Documentation: The system documentation contains the details of system design,
programs, their coding, system flow, data dictionary, process description, etc. This helps to
understand the system and permit changes to be made in the existing system to satisfy new
user needs.
Maintenance
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 must meet the scope of any future enhancement, future functionality and any other
added functional features to cope up with the latest future needs.
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.
Page 8 of 58
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.
NB
Systems Development Life Cycle (SDLC) puts emphasis on decision making
processes that affect system cost and usefulness.
These decisions must be based on full consideration of business processes, functional
requirements, and economic and technical feasibility.
The primary objectives of any SDLC is to deliver quality system which meets or
exceed customer expectations and within cost estimates, work effectively and
efficiently within the current and planned infrastructure, and is an inexpensive to
maintain.
SDLC establishes a logical order of events for conducting system development that is
controlled, measured, documented, and ultimately improved. Any software is not all
complete and there are enough rooms to add new features to existing software.
RAD
RAD model is Rapid Application Development model.
It is a type of incremental model.
In RAD model the components or functions are developed in parallel as if they were mini
projects. The developments are time boxed, delivered and then assembled into a working
prototype.
This can quickly give the customer something to see and use and to provide feedback
regarding the delivery and their requirements.
Page 9 of 58
The phases in the rapid application development (RAD) model are:
Business modeling: The information flow is identified between various business
functions.
Data modeling: Information gathered from business modeling is used to define data
objects that are needed for the business.
Process modeling: Data objects defined in data modeling are converted to achieve
the business information flow to achieve some specific business objective.
Description are identified and created for CRUD (create, read, update and delete) of
data objects.
Application generation: Automated tools are used to convert process models into
code and the actual system.
Testing and turnover: Test new components and all the interfaces.
Advantages of the RAD model:
Reduced development time.
Increases reusability of components
Quick initial reviews occur
Encourages customer feedback
Integration from very beginning solves a lot of integration issues.
Disadvantages of RAD model:
Page 10 of 58
Depends on strong team and individual performances for identifying business
requirements.
Only system that can be modularized can be built using RAD
Requires highly skilled developers/designers.
High dependency on modeling skills
Inapplicable to cheaper projects as cost of modeling and automated code generation is
very high.
When to use RAD model:
RAD should be used when there is a need to create a system that can be modularized
in 2-3 months of time.
It should be used if there’s high availability of designers for modeling and the budget
is high enough to afford their cost along with the cost of automated code generating
tools.
RAD SDLC model should be chosen only if resources with high business knowledge
are available and there is a need to produce the system in a short span of time (2-3
months).
Prototyping
The Software Prototyping refers to building software application prototypes which
display the functionality of the product under development but may not actually hold
the exact logic of the original software.
Software prototyping is becoming very popular as a software development model, as
it enables to understand customer requirements at an early stage of development.
It helps get valuable feedback from the customer and helps software designers and
developers understand about what exactly is expected from the product under
development.
What is Software Prototyping?
Prototype is a working model of software with some limited functionality.
The prototype does not always hold the exact logic used in the actual software application and is
an extra effort to be considered under effort estimation.
Prototyping is used to allow the users evaluate developer proposals and try them out before
implementation.
It also helps understand the requirements which are user specific and may not have been
considered by the developer during product design.
Page 11 of 58
Following is the stepwise approach to design a software prototype:
Basic Requirement Identification: This step involves understanding the very basics product
requirements especially in terms of user interface. The more intricate details of the internal
design and external aspects like performance and security can be ignored at this stage.
Developing the initial Prototype: The initial Prototype is developed in this stage, where the very
basic requirements are showcased and user interfaces are provided. These features may not
exactly work in the same manner internally in the actual software developed and the
workarounds are used to give the same look and feel to the customer in the prototype developed.
Review of the Prototype:The prototype developed is then presented to the customer and the
other important stakeholders in the project. The feedback is collected in an organized manner and
used for further enhancements in the product under development.
Revise and enhance the Prototype: The feedback and the review comments are discussed
during this stage and some negotiations happen with the customer based on factors like , time and
budget constraints and technical feasibility of actual implementation. The changes accepted are
again incorporated in the new Prototype developed and the cycle repeats until customer
expectations are met.
Prototypes can have horizontal or vertical dimensions.
Horizontal prototype displays the user interface for the product and gives a broader
view of the entire system, without concentrating on internal functions.
A vertical prototype on the other side is a detailed elaboration of a specific function
or a sub system in the product.
The purpose of both horizontal and vertical prototype is different. Horizontal
prototypes are used to get more information on the user interface level and the
business requirements.
It can even be presented in the sales demos to get business in the market. Vertical
prototypes are technical in nature and are used to get details of the exact functioning
of the sub systems.
For example, database requirements, interaction and data processing loads in a given
sub system.
Software Prototyping Types
There are different types of software prototypes used in the industry. Following are
the major software prototyping types used widely:
Page 12 of 58
Throwaway/Rapid Prototyping: Throwaway prototyping is also called as rapid or close ended
prototyping. This type of prototyping uses very little efforts with minimum requirement analysis
to build a prototype. Once the actual requirements are understood, the prototype is discarded and
the actual system is developed with a much clear understanding of user requirements.
Evolutionary Prototyping: Evolutionary prototyping also called as breadboard prototyping is
based on building actual functional prototypes with minimal functionality in the beginning. The
prototype developed forms the heart of the future prototypes on top of which the entire system is
built. Using evolutionary prototyping only well understood requirements are included in the
prototype and the requirements are added as and when they are understood.
Incremental Prototyping: Incremental prototyping refers to building multiple functional
prototypes of the various sub systems and then integrating all the available prototypes to form a
complete system.
Extreme Prototyping : Extreme prototyping is used in the web development domain. It consists
of three sequential phases. First, a basic prototype with all the existing pages is presented in the
html format. Then the data processing is simulated using a prototype services layer. Finally the
services are implemented and integrated to the final prototype. This process is called Extreme
Prototyping used to draw attention to the second phase of the process, where a fully functional UI
is developed with very little regard to the actual services.
Software Prototyping Application
Software Prototyping is most useful in development of systems having high level of
user interactions such as online systems. S
Systems which need users to fill out forms or go through various screens before data
is processed can use prototyping very effectively to give the exact look and feel even
before the actual software is developed.
Software that involves too much of data processing and most of the functionality is
internal with very little user interface does not usually benefit from prototyping.
Prototype development could be an extra overhead in such projects and may need lot
of extra efforts.
Software Prototyping Pros and Cons
Software prototyping is used in typical cases and the decision should be taken very
carefully so that the efforts spent in building the prototype add considerable value to
the final software developed.
The model has its own pros and cons discussed as below.
Following table lists out the pros and cons of Prototyping Model:
Page 13 of 58
Pros
Cons
Increased user involvement in the
Risk of insufficient requirement analysis
product even before implementation
owing to too much dependency on
prototype
Since a working model of the system is
displayed, the users get a better
Users may get confused in the prototypes
understanding of the system being
and actual systems.
developed.
Practically, this methodology may increase
Reduces time and cost as the defects
the complexity of the system as scope of
can be detected much earlier.
the system may expand beyond original
plans.
Quicker user feedback is available
leading to better solutions.
Developers may try to reuse the existing
prototypes to build the actual system, even
Missing functionality can be identified
when its not technically feasible
easily
The effort invested in building prototypes
Confusing or difficult functions can be
may be too much if not monitored properly
identified
Objected Oriented Model
Object-oriented modelling (OOM) is the construction of objects using a collection of
objects that contain stored values of the instance variables found within an object.
Unlike models that are record-oriented, object-oriented values are solely objects.
The object-oriented modelling approach creates the union of the application and
database development and transforms it into a unified data model and language
environment.
Object-oriented modeling allows for object identification and communication while
supporting data abstraction, inheritance and encapsulation.
Object Oriented Process
The Object Oriented Methodology of Building Systems takes the objects as the basis.
For this, first the system to be developed is observed and analyzed and the
requirements are defined as in any other method of system development. Once this is
done, the objects in the required system are identified.
Page 14 of 58
For example in case of a Banking System, a customer is an object, a chequebook is an
object, and even an account is an object.
In simple terms, Object Modelling is based on identifying the objects in a system and
their interrelationships. Once this is done, the coding of the system is done. Object
Modelling is somewhat similar to the traditional approach of system designing, in that
it also follows a sequential process of system designing but with a different approach.
The basic steps of system designing using Object Modelling may be listed as:
1WEQ
1. System Analysis
As in any other system development model, system analysis is the first phase of
development in case of Object Modeling too.
In this phase, the developer interacts with the user of the system to find out the user
requirements and analyses the system to understand the functioning.
Based on this system study, the analyst prepares a model of the desired system. This
model is purely based on what the system is required to do.
At this stage the implementation details are not taken care of. Only the model of the
system is prepared based on the idea that the system is made up of a set of interacting
objects.
The important elements of the system are emphasized.
2. System Design
System Design is the next development stage where the overall architecture of the
desired system is decided.
The system is organized as a set of sub systems interacting with each other.
While designing the system as a set of interacting subsystems, the analyst takes care
of specifications as observed in system analysis as well as what is required out of the
new system by the end user.
As the basic philosophy of Object-Oriented method of system analysis is to perceive
the system as a set of interacting objects, a bigger system may also be seen as a set of
interacting smaller subsystems that in turn are composed of a set of interacting
objects.
While designing the system, the stress lies on the objects comprising the system and
not on the processes being carried out in the system as in the case of traditional
Waterfall Model where the processes form the important part of the system.
3. Object Design
In this phase, the details of the system analysis and system design are implemented.
The Objects identified in the system design phase are designed.
Here the implementation of these objects is decided as the data structures get defined
and also the interrelationships between the objects are defined.
Let us here deviate slightly from the design process and understand first a few
important terms used in the Object-Oriented Modeling.
As already discussed, Object Oriented Philosophy is very much similar to real world
and hence is gaining popularity as the systems here are seen as a set of interacting
objects as in the real world.
Page 15 of 58
To implement this concept, the process-based structural programming is not used;
instead objects are created using data structures.
Just as every programming language provides various data types and various variables
of that type can be created, similarly, in case of objects certain data types are
predefined.
For example, we can define a data type called pen and then create and use several
objects of this data type.
This concept is known as creating a class.
Class: A class is a collection of similar objects.
It is a template where certain basic characteristics of a set of objects are defined.
The class defines the basic attributes and the operations of the objects of that type.
Defining a class does not define any object, but it only creates a template. For objects
to be actually created instances of the class are created as per the requirement of the
case.
Abstraction: Classes are built on the basis of abstraction, where a set of similar
objects are observed and their common characteristics are listed.
Of all these, the characteristics of concern to the system under observation are picked
up and the class definition is made.
The attributes of no concern to the system are left out. This is known as abstraction.
The abstraction of an object varies according to its application.
For instance, while defining a pen class for a stationery shop, the attributes of concern
might be the pen color, ink color, pen type etc., whereas a pen class for a
manufacturing firm would be containing the other dimensions of the pen like its
diameter, its shape and size etc.
Inheritance: Inheritance is another important concept in this regard.
This concept is used to apply the idea of reusability of the objects.
A new type of class can be defined using a similar existing class with a few new
features.
For instance, a class vehicle can be defined with the basic functionality of any vehicle
and a new class called car can be derived out of it with a few modifications.
This would save the developers time and effort as the classes already existing are
reused without much change.
Coming back to our development process, in the Object Designing phase of the
Development process, the designer decides onto the classes in the system based on
these concepts.
The designer also decides on whether the classes need to be created from scratch or
any existing classes can be used as it is or new classes can be inherited from them.
4. Implementation
During this phase, the class objects and the interrelationships of these classes are
translated and actually coded using the programming language decided upon.
The databases are made and the complete system is given a functional shape.
Page 16 of 58
The complete OO methodology revolves around the objects identified in the system.
When observed closely, every object exhibits some characteristics and behavior. The
objects recognize and respond to certain events.
For example, considering a Window on the screen as an object, the size of the
window gets changed when resize button of the window is clicked.
Here the clicking of the button is an event to which the window responds by changing
its state from the old size to the new size.
While developing systems based on this approach, the analyst makes use of certain
models to analyze and depict these objects
Advantages of Object Oriented Methodology
Object Oriented Methodology closely represents the problem domain. Because of this,
it is easier to produce and understand designs.
The objects in the system are immune to requirement changes. Therefore, allows
changes more easily.
Object Oriented Methodology designs encourage more re-use. New applications can
use the existing modules, thereby reduces the development cost and cycle time.
Object Oriented Methodology approach is more natural. It provides nice structures for
thinking and abstracting and leads to modular design.
Project Management
What is a Project?
Planned set of interrelated tasks to be executed over a fixed period and within certain
cost and other limitations.
It's a temporary endeavour undertaken to create a unique product, service or result.
Project documentation
Project documentation is used to define the way we manage projects
and the governance surrounding them.
is an important part of project management. It is substantiated by the essential two
functions of documentation: to make sure that project requirements are fulfilled and
to establish traceability with regard to what has been done, who has done it, and when
it has been done.
Importance of project documentation
Documentation is the best, and sometimes the only way you can keep a record of the
work done, the strategies used, the changes that occurred and all the little specifics an
average human mind is capable of forgetting. Knowing the history of the project is
essential for the current plan of action as well as how you proceed in the future.
Your clients want answers all the time. So does your team and your own boss! Last
but not the least and very importantly so, you yourself need answers too.
Documentation helps you deal with all these queries.
Page 17 of 58
While carrying out a project, you may need to document every other thing to protect
your own self from being accused falsely. People tend to blame project managers for
whatever goes wrong. Documentation in the form of letters, emails, photographs or
schedules is proof that protects you from lawsuits or other complications later on.
Documentation is evidence of a good project management. It helps you track
activities related to the project, find out if time constraints are being met, monitor
productivity and plan for the future. A good project manager will never leave any
loose ends to his project.
By carrying out this important task, the project manager and the stakeholders are all
expecting the same outcomes. There are no unpleasant surprises and no unknown
risks.
Conflicts, disagreements and problems amongst all parties seldom arise. When all
aspects of the project are right in front of everyone, it leaves little room for argument.
Documentation also helps every individual member involved to have complete
knowledge of their responsibilities, have a clear idea of what is expected from them
and how they need to manage their work.
If the correct record keeping protocol is followed, it gives the project manager
complete control over the project by being the best source of knowledge for the entire
team.
Helping to create very detailed Work Breakdown Structures which result in drafting
realistic, achievable schedules.
Reduction in unnecessary surprises and risks.
Helping to predict the project’s progress during execution and take pro-active
measures to tackle challenges.
Providing a clear understanding of the project requirements to all the stakeholders.
Details of Project Management phases
Feasibility Report
The purpose of a feasibility report is to investigate and showcase the task
requirements and to determine whether the project is worthwhile/feasible.
Feasibility is checked on the 5 primary factors – technology and system,
economic, legal, operational, and schedule.
Other feasibility factors include market, resource, culture, and financial factors.
Project Charter
Project Charter is sometimes also known as the Project Overview Statement.
A project charter includes high-level planning components of a project.
This lays the foundation of the project.
It acts as an anchor, holding you to the project's objectives and guides you as a
navigator, through the milestones.
It is a formal approval of the project.
Requirement Specification
Page 18 of 58
A requirement specification document is a complete description of the system
to be developed.
It contains all interactions the users will have with the system along with the
non-functional requirements.
Design Document
The design document showcases the high or low-level design components of
the system.
The design document used for high-level design gradually evolves to include
low-level design details.
This document describes the architectural strategies of the system.
Work Plan/Estimate
A work plan sets out the phases, activities and tasks needed to deliver a project.
The timeframes required to deliver a project, along with the resources and
milestones are also shown in a work plan.
The work plan is referred to constantly throughout the project. Actual progress
is reviewed on a daily basis against the stated plan.
It is therefore the most critical document to deliver projects successfully.
Traceability Matrix
A traceability matrix is a table that traces a requirement to the tests that are
needed to verify that the requirement is fulfilled.
A good traceability matrix will provide backward and forward traceability: a
requirement can be traced to a test and a test to a requirement.
Issue Tracker
An issue tracker manages and maintains list of issues. It helps add issues,
assign them to people, and track the status as well as current responsibilities.
It also helps develop a knowledge base to contain information on resolutions to
common problems.
Change Management Document
A change management document is used to capture progress and to record all
changes made to a system.
This helps in linking unanticipated adverse effects of a change.
Test Document
A test document includes test plan and test cases.
Page 19 of 58
A test case is a detailed procedure that fully tests a feature or an aspect of a
feature.
While a test plan describes what to test, a test case describes how to perform a
particular test.
Technical Document
Technical document includes product definition and specification, design,
manufacturing/development, quality assurance, product/system liability,
product presentation, description of features, functions and interfaces, safe and
correct use, service and repair of a technical product as well as its safe
disposal.
Functional Document
Functional specifications define the inner workings of the proposed system.
It does not include the specification how the system function will be
implemented. Instead, it focuses on what various other agents
(people/computer) might observe when interacting with the system.
User Manual
User Manual is the standard operating procedure for the system.
Transition/Rollout Plan
The rollout plan includes detailed instructions on how to implement the system
in an organization.
It includes the schematic planning of the rollout steps and phases.
It also describes the training plan for the system.
Handover Document
Handover document is a synopsis of the system with a listing of all the
deliverables of the system.
Contract Closure
Contract closure refers to the process of completing all tasks and terms that are
mentioned as deliverable and outstanding on the initial drafting of the contract. This is
only applicable in case of outsourced projects.
Lessons Learned
Lessons learned are used at midpoints of the project and at project completion to
catalog significant new understandings that have evolved as a result of the project.
They are used to build the knowledge base of the organization and to establish a
history of best and worse practices in project implementation and customer relation.
Page 20 of 58
Project management is the application of knowledge, skills, tools, and techniques
to project activities to meet the project requirements.
Project management processes fall into five groups:
1. Initiating
2. Planning
3. Executing
4. Monitoring and Controlling
5. Closing
Project management skills
1. Leadership
Project leadership was a hot topic this year.
Being able to lead your team as well as manage them is a trend that shows no sign of
abating (and that’s a good thing).
It’s really important to be able to inspire others, set the vision and lead effectively, so
if that’s not your strong point resolve to work on it now.
2. Negotiation
It would be lovely if everyone did what was best for the greater good at all times, but
projects don’t work like that in real life, do they?
Project managers with good negotiation skills will be an asset to their teams as they
seek to resolve conflicts by finding the win-win scenarios for everyone.
3. Scheduling
It should go without saying that project scheduling is a core project management skill.
However, speaking to people who manage project managers during end-of-year
review time I have heard that some of them aren’t up to scratch in this area.
Get to grips with project scheduling because a) it’s your job and b) it will help you
deliver things more successfully for others (which is also your job).
4. Cost Control
Budget management is bizarrely one of my favourite topics.
I am not a natural maths whizz but I do like a well put together spreadsheet. If I
understand the numbers and create my own tracking mechanism I can tell you to the
penny how much my project is spending.
Cost management is a critical topic for project managers.
Those without this skill will be at a disadvantage because budgets are tight. You need
to show that you can deliver your project within the cost constraints and by managing
the project finances intelligently.
5. Risk Management
The more mature project management gets as a profession, the more we find
ourselves doing projects that are unique.
The more ‘routine’ the project, the more it is likely to get outsourced or given to a
functional manager who shows an aptitude for getting things done. Project managers
will work on the more complex, transformative, unique endeavours that require
decent risk management.
Page 21 of 58
Being able to control risk (as far as you can) is a sign that you are on top of your
project.
Project sponsors hate surprises and good risk management is one way that you can
manage that.
6. Contract Management
Part of managing your project involves managing suppliers.
The vast majority of projects will have an element of supply, whether that is
something as simple as the outside caterers who bring in cakes for your launch event
or a full-on off-shoring system development firm.
Contract management is about being able to actively manage those procurements.
Previously many project managers have been able to rely on their Finance
departments to get this sort of work done (and Legal teams for managing the terms of
the deal).
Today, with everyone under pressure to do more with less, it’s falling to project
managers to pick up the slack when it comes to procurement.
7. Critical Thinking
Critical thinking is core to being able to make good decisions.
You have to weigh up the pros and cons of solutions to problems before choosing the
right way forward.
This is what distinguishes a project manager who is good at managing issues to
someone who blows issues out of the water every time.
You can build your critical thinking skills through practice and by equipping yourself
with tools and approaches to help you structure arguments logically and see things
from all angles before making the final decision.
8. Communication
If I had to pick one skill on this list to focus on during 2015 it would
be communication. We don’t do enough of it. Our stakeholders demand more of it.
We fail time and time again to meet expectations largely because we failed to
communicate effectively and often.
Think creatively about the communication channels you have got available to you
including:
Intranet
Newsletters
Page 22 of 58
Emails
Collaboration and social media tools
Team meetings/face-to-face
Web and online conferencing.
Then think about how you can apply each of these to actively serve your project next
year.
9. Project Recovery
I hope you don’t have to do project recovery next year but if you are looking for a
boost to your career then showing you know how to turn around a poorly performing
team and project will certainly set you aside from your peers.
10. Coaching
Most of the people on your project team won’t work for you (if, indeed, any of them
do).
That makes it really important that you are good at managing in a matrixed
environment but also that you are good at coaching.
Why? Because they may not have much project experience and you’ll have to coach
them to top performance.
If you are worried about not being a good coach you might be surprised to learn that
coaching skills are something that might be closer in reach than you expect.
If you sit with a child during homework and help them come to the right answers then
you are doing a form of coaching.
Some training in this area will help you apply those skills in the workplace to help
your team perform their best.
11. Task Management
This is another bread and butter task for project managers. You should be able to
create a task list, delegate work to others and keep on top of progress.
I found this was the easiest part of project management when I started because I was
naturally a list-maker.
If it doesn’t come easy to you you’ll have to develop strategies to ensure you are
always on top of your To Do list.
When you have cracked managing your own work you can help others manage theirs.
This is the best way in my experience to make sure that projects come in on time and
others take responsibility for their deliverables.
12. Quality Management
Quality management ensures that you deliver a product that is fit for purpose. What
project sponsor doesn’t want that?
Unfortunately project managers often don’t spend enough time on the quality angle of
their projects – it’s one of those processes and set of tasks that are overlooked as an
administrative overhead.
If you are a quality expert, then good for you.
But if you aren’t, seriously consider upping this on the priority list for 2015. The
better the quality of your deliverables, the better value you are offering stakeholders
and the more satisfied they will be.
13. Meetings Management
How many of your meetings this year have overrun or finished without any clear
action being agreed?
How much time have you sat in meetings wondering why you were there and what
time you can leave without it looking too bad?
Or worse, how much time have you spent on conference calls only half listening
while doing your emails or playing Candy Crush?
Page 23 of 58
Being able to sense when a meeting is going off the rails and people aren’t paying
attention is a key skill for project managers.
It’s helped by sticking to the agenda but it’s also about being able to read the body
language of people in the room to check that you are getting through the material
quickly and comprehensively.
Don’t let 2015 become another year of wasted time in meeting rooms.
14. Business Case Writing
With the ongoing focus on delivering business value, being able to write a business
case (or at least contribute one) will be a good skill to have.
Get hold of some templates so that when you are asked to finalise a business case or
review one you know what should be included.
Find some business cases from past projects and evaluate what you would do
differently.
And make sure that your next project actually has a business case – that’s a good
start!
15. A Sense of Humour
The end of 2014 has been a frantic rush to get everything done before the IT change
freeze, people’s holidays, the end of the financial year and what seems like a hundred
other deadlines.
Getting through it has largely relied on a good sense of humour and the goodwill of
colleagues prepared to pick up the slack or wait another 24 hours.
I can’t see that changing in 2015. An ability to see the funny side of project
management will keep you on an even keel during the next 12 months.
Now you have read the list which of these skills will you work on as a priority during
2015? Let us know in the comments and good luck in your project management career
this year.
Characteristics of software projects
We spend a lot of time examining software project failures but it’s equally important to
understand why some projects succeed. Here’s a short list.
1. Commitment. The business stakeholders and the technologists are committed to the project —
not just at the outset but throughout. This takes intense collaboration. There is also an
executive sponsor or champion — someone with the authority to make things happen. (If there
is a client-consultant relationship, this is doubly important.)
2. People. The right team is assembled. There is an appropriate mix of senior, mid-level and
junior people. The skill sets are also mixed and complimentary. Everyone understand their role
and how it fits into the project. Most importantly, there is a core group of exceptional people
who are capable of leading the project both administratively and technically.
3. Goals. The project has clear goals that everyone understands and accepts. This includes the
critical dates that the team has to hit. The scope of the project is narrow enough for everyone to
comprehend and embrace yet wide enough to deliver value to the business. The constraints
placed on the project are reasonable and realistic.
4. Communication. Frequent and open communication is encouraged. Everyone is willing to
share information and thus everyone knows what’s going on. Whenever the team reaches a
milestone or achieves a major successful outcome, everyone celebrates.
5. Focus. The team is focused on getting the project done. They are not distracted by cultural,
hierarchical and bureaucratic barriers. They use informal contacts and relationships to make
things happen.
Page 24 of 58
6. Learning. Everyone has the opportunity to learn and grow during the course of the project.
They are encouraged to test and experiment. When mistakes are made, they are leveraged as
learning opportunities.
7. Change. The team deals with change effectively. That means they don’t try to block change
but they don’t throw the doors wide open and allow anything to change any time. They find a
middle ground and accept change as an opportunity to learn and improve the final result.
8. Environment. The team has the right environment for getting the job done. This covers
everything from office space to desks and chairs to software development tools.
Software Crisis/Failure
A software crisis is a mismatch between what software can deliver and the capacities of computer systems,
as well as expectations of their users.
Software crisis is a term used in the early days of computing science for the difficulty of writing useful
and efficient computer programs in the required time.
Reasons of Software Crisis
•
•
•
•
•
•
•
•
Projects running over-budget
Projects running over-time
Software was very inefficient
Software was of low quality
Software often did not meet requirements
Projects were unmanageable and code difficult to maintain
Software was never delivered
Lack of communication between software developers and users.
Increase in size of software.
Increase in cost of developing a software.
Increased complexity of the problem area.
Project management problem.
Lack of understanding of the problem and its environment.
Duplication of efforts due to absence of automation in most of the software development activities.
High optimistic estimates regarding software development time and cost.
Project Planning
Project planning is part of project management, which relates to the use of schedules such as Gantt
charts to plan and subsequently report progress within the project environment.
Project Plan
A project plan, according to the Project Management Body of Knowledge (PMBOK), is: "...a
formal, approved document used to guide both project execution and project control.
The primary uses of the project plan are to document planning assumptions and decisions,
facilitate communication among project stakeholders, and document approved scope, cost,
and schedule baselines
Page 25 of 58
Characteristics of Project Plans
A project plan can be considered to have five key characteristics that have to be
managed:
Scope: defines what will be covered in a project.
Resource: what can be used to meet the scope.
Time: what tasks are to be undertaken and when.
Quality: the spread or deviation allowed from a desired standard.
Risk: defines in advance what may happen to drive the plan off course, and what will be
done to recover the situation.
Contents Of Project Plan
The project plan typically covers topics used in the project execution system and includes the following
main aspects:
Scope management
Requirements management
Schedule management
Financial management
Quality management
Resource management
Stakeholder management – New from PMBOK 5[citation needed]
Communications management
Project change management
Risk management
PROJECT PLANNING A STEP BY STEP
GUIDE
Step 1: Project Goals
Page 26 of 58
A project is successful when it has met the needs of the stakeholders. A
stakeholder is anybody directly, or indirectly impacted by the project.
As a first step, it is important to identify the stakeholders in your
project. It is not always easy to determine the stakeholders of a project,
particularly those impacted indirectly. Examples of stakeholders are:
The project sponsor
The customer who receives the deliverables
The users of the project output
The project manager and project team
Once you understand who the stakeholders are, the next step is to find
out their needs.
The best way to do this is by conducting stakeholder interviews. Take
time during the interviews to draw out the requirements that create real
benefits.
Sometimes stakeholders will talk about needs that aren't relevant and
don't deliver benefits. These can be recorded and set as a low priority.
The next step, once you have conducted all the interviews and have a
comprehensive list of needs is to prioritise them.
From the prioritised list, create a set of easily measurable goals. A
good technique for doing this is to review them against the SMART
principle.
This way, the achievement of the goal will be easy to identify.
Once you have established a clear set of goals, they should be recorded
in the project plan.
It can be useful also to include the needs and expectations of your
stakeholders.
Now you have completed the most difficult part of the planning
process; it's time to move on and look at the project deliverables.
Step 2: Project Deliverables
Page 27 of 58
Using the goals you have defined in step 1, create a list of things the
project needs to deliver to meet those goals. Specify when and how to
deliver each item.
Add the deliverables to the project plan with an estimated delivery
date. You will establish more accurate delivery dates during the
scheduling phase, which is next.
Step 3: Project Schedule
Create a list of tasks that need to be carried out for each deliverable
identified in step 2. For each task determine the following:
The amount of effort (hours or days) required for completing the task
The resource who will carry out the task
Once you have established the amount of effort for each task, you can
work out the effort required for each deliverable, and an accurate
delivery date. Update your deliverables section with the more precise
delivery dates.
At this point in the planning, you could choose to use a software
package such as Microsoft Project to create your project schedule.
Alternatively, use one of the many free templates available. Input all of
the deliverables, tasks, durations and the resources who will complete
each task.
A common problem discovered at this point is when you have an
imposed delivery deadline from the sponsor that is not realistic based
on your estimates. If you discover this is the case, you must contact the
sponsor immediately. The options you have in this situation are:
Renegotiate the deadline (project delay)
Employ additional resources (increased cost)
Reduce the scope of the project (less delivered)
Use the project schedule to justify pursuing one of these options.
Step 4: Supporting Plans
Page 28 of 58
This section deals with the plans you should create as part of the
planning process. These can be included directly in the plan.
Human Resource Plan
Identify, by name, the individuals and organisations with a leading role
in the project. For each, describe their roles and responsibilities on the
project.
Next, specify the number and type of people needed to carry out the
project. For each resource detail start dates, the estimated duration and
the method you will use for obtaining them.
Create a single sheet containing this information.
Communications Plan
Create a document showing who is to be kept informed about the
project and how they will receive the information.
The most common mechanism is a weekly or monthly status report,
describing how the project is performing, milestones achieved and the
work you've planned for the next period.
Risk Management Plan
Risk management is an important part of project management.
Although often overlooked, it is important to identify as many risks to
your project as possible and be prepared if something bad happens.
Here are some examples of common project risks:
Time and cost estimate too optimistic
Customer review and feedback cycle too slow
Unexpected budget cuts
Unclear roles and responsibilities
No stakeholder input obtained
Not clearly understanding stakeholder needs
Page 29 of 58
Stakeholders changing requirements after the project has started
Stakeholders adding new requirements after the project has started
Poor communication resulting in misunderstandings, quality problems
and rework
Lack of resource commitment
Risks can be tracked using a simple risk log. Add each risk you have
identified to your risk log; write down what you will do in the event it
occurs, and what you will do to prevent it from happening.
Review your risk log on a regular basis, adding new risks as they occur
during the life of the project.
Remember, if you ignore risks, they don't go away.
Software development Plan
The Software Development Plan (SDP) describes a developer’s plans for conducting a
software development effort.
The SDP provides the acquirer insight and a tool for monitoring the processes to be
followed for software development.
It also details methods to be used and approach to be followed for each activity,
organization, and resources
What is a Quality Assurance Plan?
A quality assurance plan is a document, constructed by the project team, meant to
ensure the final products are of the utmost quality.
A quality assurance plan contains a set of documented activities meant to ensure that
customers are satisfied with the goods or services a company provides.
There are four steps of the quality assurance process: Plan, Do, Check, and Act.
Validation Plans (VP)
Validation Plans define the scope and goals of a validation project.
The Validation Plan is written at the start of the validation project (sometimes
concurrently with the user requirement specification) and is usually specific to a
single validation project.
A Validation Plan should include:
Deliverables (documents) to be generated during the validation process
Resources, departments, and personnel to participate in the validation project
Page 30 of 58
Time-lines for completing the validation project
Acceptance criteria to confirm that the system meets defined requirements
Compliance requirements for the system, including how the system will meet these
requirements
Configuration Management (CM) Plan
The Configuration Management (CM) Plan describes all Configuration and
Change Control Management (CCM) activities you will perform during the
course of the product or project lifecycle.
It details the schedule of activities, the assigned responsibilities, and the
required resources, including staff, tools, and computer facilities.
Maintenance Plans
Software Maintenance Plans are different than other technical documents in that the
focus is on how to modify software AFTER it has been released and is now in
operations. Most other documents focus on planning, development or testing.
Software maintenance in software engineering is the modification of a software product after
delivery to correct faults, to improve performance or other attributes.
Developmental Plan. Staff development must be intentional, active, and potent. A
plan for individual growth should reflect current personal and professional status
regarding attributes needed to perform assigned duties, short- and long-term goals,
and alternative methods for achieving those goals.
Project Scheduling
In project management, a schedule is a listing of a project's milestones, activities,
and deliverables, usually with intended start and finish dates.
Those items are often estimated by other information included in the project schedule
of resource allocation, budget, task duration, and linkages of dependencies and
scheduled events.
The project schedule is the tool that communicates what work needs to be performed,
which resources of the organization will perform the work and the timeframes in
which that work needs to be performed.
The project schedule should reflect all of the work associated with delivering the
project on time.
Without a full and complete schedule, the project manager will be unable to
communicate the complete effort, in terms of cost and resources, necessary to deliver
the project.
Tools for Schedule development
1. Critical Path method (CPM)
2. Gantt Chart
Page 31 of 58
Critical Path method (CPM)
The critical path method (CPM) is a step-by-step project
management technique for process planning that defines critical and noncritical tasks with the goal of preventing time-frame problems and
process bottlenecks.
The CPM is ideally suited to projects consisting of numerous activities that
interact in a complex manner.
In applying the CPM, there are several steps that can be summarized as
follows:
Define the required tasks and put them down in an ordered (sequenced) list.
Create a flowchart or other diagram showing each task in relation to the others.
Identify the critical and non-critical relationships (paths) among tasks.
Determine the expected completion or execution time for each task.
Locate or devise alternatives (backups) for the most critical paths.
Network diagram above
What is a Gantt chart?
A Gantt chart, commonly used in project management, is one of the most popular and useful ways
of showing activities (tasks or events) displayed against time.
Page 32 of 58
On the left of the chart is a list of the activities and along the top is a suitable time scale. Each
activity is represented by a bar; the position and length of the bar reflects the start date, duration
and end date of the activity.
This allows you to see at a glance:
What the various activities are
When each activity begins and ends
How long each activity is scheduled to last
Where activities overlap with other activities, and by how much
The start and end date of the whole project
To summarize, a Gantt chart shows you what has to be done (the activities) and when (the
schedule).
A simple Gantt chart
SOFTWARE DESIGN
Software design is a process to conceptualize the software requirements into
software implementation.
Software design takes the user requirements as challenges and tries to find optimum
solution.
While the software is being conceptualized, a plan is chalked out to find the best
possible design for implementing the intended solution.
There are multiple variants of software design strategies. Let us study them briefly:
Structured Design
Page 33 of 58
Structured design is a conceptualization of problem into several well-organized
elements of solution.
It is basically concerned with the solution design.
Benefit of structured design is, it gives better understanding of how the problem is
being solved.
Structured design also makes it simpler for designer to concentrate on the problem
more accurately.
Structured design is mostly based on ‘divide and conquer’ strategy where a problem
is broken into several small problems and each small problem is individually solved
until the whole problem is solved.
The small pieces of problem are solved by means of solution modules. Structured
design emphasis that these modules be well organized in order to achieve precise
solution.
These modules are arranged in hierarchy. They communicate with each other. A
good structured design always follows some rules for communication among
multiple modules, namely Cohesion - grouping of all functionally related elements.
Coupling - communication between different modules.
A good structured design has high cohesion and low coupling arrangements.
Function Oriented Design
In function-oriented design, the system is comprised of many smaller sub-systems
known as functions.
These functions are capable of performing significant task in the system.
The system is considered as top view of all functions.
Function oriented design inherits some properties of structured design where divide
and conquer methodology is used.
This design mechanism divides the whole system into smaller functions, which
provides means of abstraction by concealing the information and their operation.
Page 34 of 58
These functional modules can share information among themselves by means of
information passing and using information available globally.
Another characteristic of functions is that when a program calls a function, the
function changes the state of the program, which sometimes is not acceptable by
other modules.
Function oriented design works well where the system state does not matter and
program/functions work on input rather than on a state.
Design Process
The whole system is seen as how data flows in the system by means of data flow diagram.
DFD depicts how functions changes data and state of entire system.
The entire system is logically broken down into smaller units known as functions on the basis of
their operation in the system.
Each function is then described at large.
Object Oriented Design
Object oriented design works around the entities and their characteristics instead of
functions involved in the software system.
This design strategies focuses on entities and its characteristics.
The whole concept of software solution revolves around the engaged entities.
Let us see the important concepts of Object Oriented Design:
Objects - All entities involved in the solution design are known as objects. For example, person,
banks, company and customers are treated as objects. Every entity has some attributes associated
to it and has some methods to perform on the attributes.
Classes - A class is a generalized description of an object. An object is an instance of a class.
Class defines all the attributes, which an object can have and methods, which defines the
functionality of the object.
In the solution design, attributes are stored as variables and functionalities are defined by means
of methods or procedures.
Page 35 of 58
Encapsulation - In OOD, the attributes (data variables) and methods (operation on the data) are
bundled together is called encapsulation. Encapsulation not only bundles important information of
an object together, but also restricts access of the data and methods from the outside world. This is
called information hiding.
Inheritance - OOD allows similar classes to stack up in hierarchical manner where the lower or
sub-classes can import, implement and re-use allowed variables and methods from their
immediate super classes. This property of OOD is known as inheritance. This makes it easier to
define specific class and to create generalized classes from specific ones.
Polymorphism - OOD languages provide a mechanism where methods performing similar tasks
but vary in arguments, can be assigned same name. This is called polymorphism, which allows a
single interface performing tasks for different types. Depending upon how the function is invoked,
respective portion of the code gets executed.
Design Process
Software design process can be perceived as series of well-defined steps. Though it varies
according to design approach (function oriented or object oriented, yet It may have the
following steps involved:
A solution design is created from requirement or previous used system and/or system sequence
diagram.
Objects are identified and grouped into classes on behalf of similarity in attribute characteristics.
Class hierarchy and relation among them is defined.
Application framework is defined.
Software Design Approaches
Here are two generic approaches for software designing:
Top Down Design
We know that a system is composed of more than one sub-systems and it contains a
number of components.
Further, these sub-systems and components may have their on set of sub-system and
components and creates hierarchical structure in the system.
Top-down design takes the whole software system as one entity and then
decomposes it to achieve more than one sub-system or component based on some
characteristics.
Page 36 of 58
Each sub-system or component is then treated as a system and decomposed further.
This process keeps on running until the lowest level of system in the top-down
hierarchy is achieved.
Top-down design starts with a generalized model of system and keeps on defining
the more specific part of it.
When all components are composed the whole system comes into existence.
Top-down design is more suitable when the software solution needs to be designed
from scratch and specific details are unknown.
Bottom-up Design
The bottom up design model starts with most specific and basic components.
It proceeds with composing higher level of components by using basic or lower level
components.
It keeps creating higher level components until the desired system is not evolved as
one single component.
With each higher level, the amount of abstraction is increased.
Bottom-up strategy is more suitable when a system needs to be created from some
existing system, where the basic primitives can be used in the newer system.
Both, top-down and bottom-up approaches are not practical individually. Instead, a
good combination of both is used.
USER INTERFACE
User interface design (UI) or user interface engineering is the design of user
interfaces for machines and software, such as computers, home appliances, mobile devices, and
other electronic devices, with the focus on maximizing usability and the user experience.
The goal of user interface design is to make the user's interaction as simple and efficient as
possible, in terms of accomplishing user goals (user-centered design).
User Interface Design Basics
User Interface (UI) Design focuses on anticipating what users might need to do and
ensuring that the interface has elements that are easy to access, understand, and use to
facilitate those actions.
UI brings together concepts from interaction design, visual design, and information
architecture.
Page 37 of 58
Choosing Interface Elements
Users have become familiar with interface elements acting in a certain way, so try to
be consistent and predictable in your choices and their layout.
Doing so will help with task completion, efficiency, and satisfaction.
Interface elements include but are not limited to:
Input Controls: buttons, text fields, checkboxes, radio buttons, dropdown lists, list boxes,
toggles, date field
Navigational Components: breadcrumb, slider, search field, pagination, slider, tags, icons
Informational Components: tooltips, icons, progress bar, notifications, message boxes, modal
windows
Containers: accordion
There are times when multiple elements might be appropriate for displaying content.
When this happens, it’s important to consider the trade-offs.
For example, sometimes elements that can help save you space, put more of a burden
on the user mentally by forcing them to guess what is within the dropdown or what
the element might be.
Best Practices for Designing an Interface
Everything stems from knowing your users, including understanding their goals,
skills, preferences, and tendencies.
Once you know about your user, make sure to consider the following when designing
your interface:
Keep the interface simple. The best interfaces are almost invisible to the user. They avoid
unnecessary elements and are clear in the language they use on labels and in messaging.
Create consistency and use common UI elements. By using common elements in your UI, users
feel more comfortable and are able to get things done more quickly. It is also important to create
patterns in language, layout and design throughout the site to help facilitate efficiency. Once a
user learns how to do something, they should be able to transfer that skill to other parts of the
site.
Be purposeful in page layout. Consider the spatial relationships between items on the page and
structure the page based on importance. Careful placement of items can help draw attention to the
most important pieces of information and can aid scanning and readability.
Strategically use color and texture. You can direct attention toward or redirect attention away
from items using color, light, contrast, and texture to your advantage.
Page 38 of 58
Use typography to create hierarchy and clarity. Carefully consider how you use typeface.
Different sizes, fonts, and arrangement of the text to help increase scanability, legibility and
readability.
Make sure that the system communicates what’s happening. Always inform your users of
location, actions, changes in state, or errors. The use of various UI elements to communicate
status and, if necessary, next steps can reduce frustration for your user.
Think about the defaults. By carefully thinking about and anticipating the goals people bring to
your site, you can create defaults that reduce the burden on the user. This becomes particularly
important when it comes to form design where you might have an opportunity to have some fields
pre-chosen or filled out.
DATA STRUCTURE AND ALGORITHMS
A data structure is a specialized format for organizing and storing data.
General data structure types include the array, the file, the record, the table,
the tree, and so on. Any data structure is designed to organize data to suit a
specific purpose so that it can be accessed and worked with in appropriate
ways.
An algorithm is a procedure or formula for solving a problem, based
on conductiong a sequence of specified actions. A computer program can be
viewed as an elaborate algorithm. In mathematics and computer science, an
algorithm usually means a small procedure that solves a recurrent problem.
Variables are used to store information to be referenced and manipulated in a computer
program. They also provide a way of labeling data with a descriptive name, so our
programs can be understood more clearly by the reader and ourselves. It is helpful to
think of variables as containers that hold information. Their sole purpose is to label and
store data in memory. This data can then be used throughout your program.
Pseudo code structures (see pdf tutorial on pseudocode basics)
Sorting algorithms
Bubble sort
Page 39 of 58
VB code for bubble sort
Public Sub BubbleSort(ByRef ArrayIn() As Long)
Dim i, j As Integer
Dim t
As Long
For i = UBound(ArrayIn) To 0 Step -1
For j = 0 To i - 1
If ArrayIn(j) > ArrayIn(j + 1) Then
Call swap(ArrayIn(j), ArrayIn(j + 1))
End If
Next j
Next i
End Sub
Private Sub swap(ByRef data1 As Long, ByRef data2 As Long)
Dim temp As Long
temp = data1
data1 = data2
data2 = temp
End Sub
Quick sort
Page 40 of 58
QuickSort is a Divide and Conquer algorithm. It picks an element as pivot and partitions the given aarray around
the picked pivot. There are many different versions of quickSort that pick pivot in different ways.
1. Always pick first element as pivot.
2. Always pick last element as pivot (implemented below)
3. Pick a random element as pivot.
4. Pick median as pivot.
The key process in quickSort is partition(). Target of partitions is, given an array and an element x of array as
pivot, put x at its correct position in sorted array and put all smaller elements (smaller than x) before x, and put
all greater elements (greater
ater than x) after x. All this should be done in linear time.
VB QUICK SORT PROGRAM
1. Option Explicit
2.
3. Private Sub Form_Load()
4.
Dim MyStrArray() As String,
String K As Long, Q As Long
5.
ReDim MyStrArray(1 To 10)
6.
7.
Randomize
8.
9.
Debug.Print "Unsorted
sorted strings:"
10.
For K = LBound(MyStrArray
MyStrArray) To UBound(MyStrArray)
11.
12.
' create a random string
13.
MyStrArray(K) = String
String(10, " ")
14.
For Q = 1 To 10
15.
Mid$(MyStrArray(K
K), Q, 1) = Chr(Asc("A") + Fix(26 * Rnd))
16.
Next Q
17.
18.
' print the string to the immediate window
19.
Debug.Print MyStrArray
MyStrArray(K)
20.
Next K
21.
22.
' sort the array
23.
QuickSort MyStrArray, LBound
LBound(MyStrArray), UBound(MyStrArray)
24.
25.
' print the sorted string to the immediate window
win
26.
Debug.Print vbNewLine & "Sorted strings:"
27.
For K = LBound(MyStrArray
MyStrArray) To UBound(MyStrArray)
Page 41 of 58
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
Debug.Print MyStrArray(K)
Next K
End Sub
Private Sub QuickSort(C() As String, ByVal First As Long, ByVal Last As Long)
'
' Made by Michael Ciurescu (CVMichael from vbforums.com)
' Original thread: [url]http://www.vbforums.com/showthread.php?t=231925[/url]
'
Dim Low As Long, High As Long
Dim MidValue As String
Low = First
High = Last
MidValue = C((First + Last) \ 2)
Do
While C(Low) < MidValue
Low = Low + 1
Wend
While C(High) > MidValue
High = High - 1
Wend
If Low <= High Then
Swap C(Low), C(High)
Low = Low + 1
High = High - 1
End If
Loop While Low <= High
If First < High Then QuickSort C, First, High
If Low < Last Then QuickSort C, Low, Last
End Sub
Private Sub Swap(ByRef A As String, ByRef B As String)
Dim T As String
T=A
A=B
B=T
End Sub
SEARCHING ALGORITHMS
Linear search
Linear Search
Problem: Given an array arr[] of n elements, write a function to search a given element x in arr[].
A simple approach is to do linear search, i.e
Start from the leftmost element of arr[] and one by one compare x with each element of arr[]
If x matches with an element, return the index.
If x doesn’t match with any of elements, return -1.
Page 42 of 58
Example:
Binary search
Binary Search
Given a sorted array
y arr[] of n elements, write a function to search a given element x in arr[].
A simple approach is to do linear search.The time complexity of above algorithm is O(n). Another approach
to perform thee same task is using Binary Search.
Binary Search: Search a sorted array by repeatedly dividing the search interval in half. Begin with an
interval covering the whole array. If the value of the search key is less than the item in the middle of the
interval,, narrow the interval to the lower half. Otherwise narrow it to the upper half. Repeatedly check until the
value is found or the interval is empty.
Page 43 of 58
Example:
Task: Use Visual basic programming to implement linear and binary search.
DYNAMIC AND STATIC DATA STRUCTURES
NORMALISATION
1st Normal Form Definition
A database is in first normal form if it satisfies the following conditions:
Contains only atomic values
There are no repeating groups
An atomic value is a value that cannot be divided. For example, in the table shown below, the
values in the [Color] column in the first row can be divided into "red" and "green", hence
[TABLE_PRODUCT] is not in 1NF.
A repeating group means that a table contains two or more columns that are closely related.
For example, a table that records data on a book and its author(s) with the following columns:
[Book ID], [Author 1], [Author 2], [Author 3] is not in 1NF because [Author 1], [Author 2],
and [Author 3] are all repeating the same attribute.
1st Normal Form Example
How do we bring an unnormalized table into first normal form? Consider the following
example:
Page 44 of 58
This table is not in first normal form because the [Color] column can contain multiple values.
For example, the first row includes values "red" and "green."
To bring this table to first normal form, we split the table into two tables and now we have
the resulting tables:
2nd Normal Form Definition
A database is in second normal form if it satisfies the following conditions:
It is in first normal form
All non-key attributes are fully functional dependent on the primary key
In a table, if attribute B is functionally dependent on A, but is not functionally dependent on a
proper subset of A, then B is considered fully functional dependent on A. Hence, in a 2NF
table, all non-key attributes cannot be dependent on a subset of the primary key. Note that if
the primary key is not a composite key, all non-key attributes are always fully functional
dependent on the primary key. A table that is in 1st normal form and contains only a single
key as the primary key is automatically in 2nd normal form.
2nd Normal Form Example
Consider the following example:
Page 45 of 58
This table has a composite primary key [Customer ID, Store ID]. The non-key attribute is
[Purchase Location]. In this case, [Purchase Location] only depends on [Store ID], which is
only part of the primary key. Therefore, this table does not satisfy second normal form.
To bring this table to second normal form, we break the table into two tables, and now we
have the following:
What we have done is to remove the partial functional dependency that we initially had.
Now, in the table [TABLE_STORE], the column [Purchase Location] is fully dependent on
the primary key of that table, which is [Store ID].
SYTEM SECURITY
Top 10 Secure Coding Practices/Programming Practices
1. Validate input. Validate input from all untrusted data sources. Proper input validation can eliminate the
vast majority of software vulnerabilities. Be suspicious of most external data sources, including command
line arguments, network interfaces, environmental variables, and user controlled files [Seacord 05].
2. Heed compiler warnings. Compile code using the highest warning level available for your compiler and
eliminate warnings by modifying the code [C MSC00-A, C++ MSC00-A]. Use static and dynamic analysis
tools to detect and eliminate additional security flaws.
3. Architect and design for security policies. Create a software architecture and design your software to
implement and enforce security policies. For example, if your system requires different privileges at
different times, consider dividing the system into distinct intercommunicating subsystems, each with an
appropriate privilege set.
4. Keep it simple. Keep the design as simple and small as possible [Saltzer 74, Saltzer 75]. Complex designs
increase the likelihood that errors will be made in their implementation, configuration, and use.
Additionally, the effort required to achieve an appropriate level of assurance increases dramatically as
security mechanisms become more complex.
Page 46 of 58
5. Default deny. Base access decisions on permission rather than exclusion. This means that, by default,
access is denied and the protection scheme identifies conditions under which access is permitted [Saltzer
74, Saltzer 75].
6. Adhere to the principle of least privilege. Every process should execute with the the least set of
privileges necessary to complete the job. Any elevated permission should be held for a minimum time.
This approach reduces the opportunities an attacker has to execute arbitrary code with elevated privileges
[Saltzer 74, Saltzer 75].
7. Sanitize data sent to other systems. Sanitize all data passed to complex subsystems [C STR02-A] such as
command shells, relational databases, and commercial off-the-shelf (COTS) components. Attackers may
be able to invoke unused functionality in these components through the use of SQL, command, or other
injection attacks. This is not necessarily an input validation problem because the complex subsystem being
invoked does not understand the context in which the call is made. Because the calling process understands
the context, it is responsible for sanitizing the data before invoking the subsystem.
8. Practice defense in depth. Manage risk with multiple defensive strategies, so that if one layer of defense
turns out to be inadequate, another layer of defense can prevent a security flaw from becoming an
exploitable vulnerability and/or limit the consequences of a successful exploit. For example, combining
secure programming techniques with secure runtime environments should reduce the likelihood that
vulnerabilities remaining in the code at deployment time can be exploited in the operational environment
[Seacord 05].
9. Use effective quality assurance techniques. Good quality assurance techniques can be effective in
identifying and eliminating vulnerabilities. Fuzz testing, penetration testing, and source code audits should
all be incorporated as part of an effective quality assurance program. Independent security reviews can lead
to more secure systems. External reviewers bring an independent perspective; for example, in identifying
and correcting invalid assumptions [Seacord 05].
10. Adopt a secure coding standard. Develop and/or apply a secure coding standard for your target
development language and platform.
COMMON THREATS AND SOFTWARE VULNERABILITIES
1. Malware
is any program or file that is harmful to a computer user. Malwareincludes computer
viruses, worms, Trojan horses and spyware.
2. Botnets
A botnet is a collection of internet-connected devices, which may include PCs, servers,
mobile devices and internet of things devices that are infected and controlled by a common
type of malware. Users are often unaware of a botnet infecting their system.
Infected devices are controlled remotely by threat actors, often cybercriminals, and are used
for specific functions, so the malicious operations stay hidden to the user. Botnets are
commonly used to send email spam, engage in click fraud campaigns and generate malicious
traffic for distributed denial-of-service attacks.
Page 47 of 58
How botnets work
The term botnet is derived from the words robot and network. A bot in this case is a device
infected by malware, which then becomes part of a network, or net, of infected devices
controlled by a single attacker or attack group.
The botnet malware typically looks for vulnerable devices across the internet, rather than
targeting specific individuals, companies or industries. The objective for creating a botnet is
to infect as many connected devices as possible, and to use the computing power and
resources of those devices for automated tasks that generally remain hidden to the users of
the devices.
For example, an ad fraud botnet that infects a user's PC will take over the system's web
browsers to divert fraudulent traffic to certain online advertisements. However, to stay
concealed, the botnet won't take complete control of the web browsers, which would alert the
user. Instead, the botnet may use a small portion of the browser's processes, often running in
the background, to send a barely noticeable amount of traffic from the infected device to the
targeted ads.
Phishing
Phishing is a form of fraud in which an attacker masquerades as a reputable entity or person
in email or other communication channels. The attacker uses phishing emails to distribute
malicious links or attachments that can perform a variety of functions, including the
extraction of login credentials or account information from victims.
How phishing works
Phishing attacks typically rely on social networking techniques applied to email or other
electronic communication methods, including direct messages sent over social networks,
SMS text messages and other instant messaging modes.
Phishers may use social engineering and other public sources of information, including social
networks like LinkedIn, Facebook and Twitter, to gather background information about the
victim's personal and work history, his interests, and his activities.
Control measures
Page 48 of 58
Firewalls
A firewall is a network security system, either hardware- or software-based, that uses rules to
control incoming and outgoing network traffic.
A firewall acts as a barrier between a trusted network and and an untrusted network. A
firewall controls access to the resources of a network through a positive control model. This
means that the only traffic allowed onto the network is defined in the firewall policy; all other
traffic is denied.
Tools used to eliminate vulnerabilities at programming level
Vulnerability Analysis Tools
During the process of producing software products, vendors unintentionally create
vulnerabilities that are later discovered and mitigated. By paying greater attention to the early
phases of the development lifecycle, we can change the nature of the engineering process to
detect and eliminate-and later avoid-vulnerabilities before products ship.
We help you understand how vulnerabilities are created and discovered. Our open source
tools help you find vulnerabilities so that you can eliminate them from your software before
you release it. Contact us if you want to discuss these tools or if you need more information
about our tools or work.
Basic Fuzzing Framework (BFF)
Basic Fuzzing Framework (BFF) is a mutational file fuzz testing tool that consists of a
Debian Linux virtual machine, the zzuf fuzzer, and a few associated scripts. A version of the
BFF that runs natively on Mac OS X is also available. Learn more about this tool, and
download a copy to begin fuzzing on your own.
Failure Observation Engine (FOE)
Failure Observation Engine (FOE) is a mutational file-based fuzz testing tool for finding
defects in applications that run on the Windows platform.
CERT Triage Tools
CERT Triage Tools consist of a triage script and a GNU Debugger (GDB) extension named
'exploitable' that classify Linux application defects by severity. We originally developed the
CERT Triage Tools in order to assist software vendors and analysts in identifying the impact
of defects discovered through techniques such as fuzz testing. As of May 2014, the CERT
Triage Tools project has been transitioned to the GDB 'exploitable' plugin project on GitHub.
CERT Tapioca
Page 49 of 58
CERT Tapioca is a virtual machine appliance (OVA) for performing man-in-the-middle
network traffic analysis of software and devices.
Dranzer
Dranzer discovers certain classes of vulnerabilities in Microsoft Windows ActiveX controls.
Several prominent information technology vendors are already using Dranzer to help
discover vulnerabilities in the ActiveX controls they produce before the products are shipped.
We are applying and expanding what we learned from developing that tool to develop tools
and techniques that address other technologies.
Risk Management (See pdf files Risk management)
Code of ethics (See pdf code of ethics)
Data Protection and legislation
The Data Protection Act controls how your personal information is used by organisations,
businesses or the government.
Everyone responsible for using data has to follow strict rules called ‘data protection
principles’. They must make sure the information is:
used fairly and lawfully
used for limited, specifically stated purposes
used in a way that is adequate, relevant and not excessive
accurate
kept for no longer than is absolutely necessary
handled according to people’s data protection rights
kept safe and secure
not transferred outside the European Economic Area without adequate protection
There is stronger legal protection for more sensitive information, such as:
ethnic background
political opinions
religious beliefs
health
sexual health
criminal records
Zimbabwe/ 5.1 General legislation
5.1.8 Data protection laws
Page 50 of 58
Access to Information and Protection of Privacy Act Chapter 10:27
This Act was enacted to provide members of the public with a right of access to records and
information held by public bodies; to make public bodies accountable by giving the public a
right to request correction of misrepresented personal information; to prevent the
unauthorised collection, use or disclosure of personal information by public bodies; to protect
personal privacy; to provide for the regulation of the mass media; to establish a Media and
Information Commission and to provide for matters connected therewith or incidental to the
foregoing.
Interception of Communications Act Chapter 11:20
An Act enacted to provide for the lawful interception and monitoring of certain
communications in the course of their transmission through a telecommunication, postal or
any other related service or system in Zimbabwe; to provide for the establishment of a
monitoring centre; and to provide for any other matters connected with or incidental to the
foregoing.
Censorship and Entertainments Control Act Chapter 10:04
An Act enacted to regulate and control the public exhibition of films, the importation,
production, dissemination and possession of undesirable or prohibited video and film
material, publications, pictures,
Statues and records and the giving of public entertainments; to regulate theatres and like
places of public entertainment in the interests of safety; and to provide for matters incidental
to the foregoing.
Data Security Policies
Essential Elements of a Data Security Policy
1. Safeguard Data Privacy: Employees must understand that your privacy policy is a
pledge to your customers that you will protect their information. Data should only be
used in ways that will keep customer identity and the confidentiality of information
secure. Of course, your employees and organizations must conform to all applicable
laws and regulations.
2. Establish Password Management: A password policy should be established for all
employees or temporary workers who will access corporate resources. In
general, password complexity should be established according to the job functions
and data security requirements. Passwords should never be shared.
3. Govern Internet Usage: Most people use the internet without a thought to the harm
that can ensue. Employee misuse of the internet can place your company in an
awkward, or even illegal, position. Establishing limits on employee internet usage in
the workplace may help avoid these situations. Every organization should decide how
employees can and should access the web. You want employees to be productive, and
this may be the main concern for limiting internet usage, but security concerns should
also dictate how internet guidelines are formulated.
Page 51 of 58
4. Manage Email Usage: Many data breaches are a result of employee misuse of email
that can result in the loss or theft of data and the accidental downloading of viruses or
other malware. Clear standards should be established regarding use of emails,
message content, encryption and file retention.
5. Govern and Manage Company-Owned Mobile Devices: When organizations
provide mobile devices for their employees to use, a formal process should be
implemented to help ensure that mobile devices are secure and used appropriately.
Requiring employees to be responsible for protecting their devices from theft and
requiring password protection in accordance with your password policy should be
minimum requirements.
6. Establish an Approval Process for Employee-Owned Mobile Devices: With the
increased capabilities of consumer devices, such as smart phones and tablets, it has
become easy to interconnect these devices to company applications and infrastructure.
Use of these devices to interconnect to company email, calendaring and other services
can blur the lines between company controls and consumer controls. Employees who
request and are approved to have access to company information via their personal
devices should understand and accept the limitations and controls imposed by the
company.
7. Govern Social Media: All users of social media need to be aware of the risks
associated with social media networking. A strong social media policy is crucial for
any business that seeks to use social networking to promote its activities and
communicate with its customers. Active governance can help ensure employees speak
within the parameters set by their company and follow data privacy best practices.
8. Oversee Software Copyright and Licensing: There are many good reasons for
employees to comply with software copyright and licensing agreements.
Organizations are obliged to adhere to the terms of software usage agreements and
employees should be made aware of any usage restrictions. Also, employees should
not download and use software that has not been reviewed and approved by the
company.
9. Report Security Incidents: A procedure should be in place for employees or
contractors to report malicious malware in the event it is inadvertently imported. All
employees should know how to report incidents of malware and what steps to take to
help mitigate damage.
Cybercrime
Cybercrime, also called computer crime, is any illegal activity that involves a computer or
network-connected device, such as a mobile phone. The Department of Justice divides
cybercrime into three categories: crimes in which the computing device is the target, for
example, to gain network access; crimes in which the computer is used as a weapon, for
example, to launch a denial of service (DoS) attack; and crimes in which the computer is used
as an accessory to a crime, for example, using a computer to store illegally-obtained data.
Page 52 of 58
QUALITY ASSURANCE AND TESTING
Testing approaches and levels (see A level notes pdf)
Software quality attributes
Software Quality Attributes are: Correctness, Reliability, Adequacy, Learnability,
Robustness, Maintainability, Readability, Extensibility, Testability, Efficiency, Portability.
Correctness: The correctness of a software system refers to:
- Agreement of program code with specifications
- Independence of the actual application of the software system.
The correctness of a program becomes especially critical when it is embedded in a complex
software system.
Reliability: Reliability of a software system derives from
- Correctness
- Availability
The behavior over time for the fulfillment of a given specification depends on the reliability
of the software system.
Reliability of a software system is defined as the probability that this system fulfills a
function (determined by the specifications) for a specified number of input trials under
specified input conditions in a specified time interval (assuming that hardware and input are
free of errors).
A software system can be seen as reliable if this test produces a low error rate (i.e., the
probability that an error will occur in a specified time interval.)
The error rate depends on the frequency of inputs and on the probability that an individual
input will lead to an error.
Adequacy: Factors for the requirement of Adequacy:
- The input required of the user should be limited to only what is necessary. The software
system should expect information only if it is necessary for the functions that the user wishes
to carry out. The software system should enable flexible data input on the part of the user and
should carry out plausibility checks on the input. In dialog-driven software systems, we vest
particular importance in the uniformity, clarity and simplicity of the dialogs.
- The performance offered by the software system should be adapted to the wishes of the user
with the consideration given to extensibility; i.e., the functions should be limited to these in
the specification.
- The results produced by the software system: The results that a software system delivers
should be output in a clear and wellstructured form and be easy to interpret. The software
system should afford the user flexibility with respect to the scope, the degree of detail, and
the form of presentation of the results. Error messages must be provided in a form that is
comprehensible for the user.
Learnability: Learnability of a software system depends on:
Page 53 of 58
- The design of user interfaces
- The clarity and the simplicity of the user instructions (tutorial or user manual).
The user interface should present information as close to reality as possible and permit
efficient utilization of the software’s failures.
The user manual should be structured clearly and simply and be free of all dead weight. It
should explain to the user what the software system should do, how the individual functions
are activated, what relationships exist between functions, and which exceptions might arise
and how they can be corrected. In addition, the user manual should serve as a reference that
supports the user in quickly and comfortably finding the correct answers to questions.
Robustness: Robustness reduces the impact of operational mistakes, erroneous input data,
and hardware errors.
A software system is robust if the consequences of an error in its operation, in the input, or in
the hardware, in relation to a given application, are inversely proportional to the probability
of the occurrence of this error in the given application.
- Frequent errors (e.g. erroneous commands, typing errors) must be handled with particular
care.
- Less frequent errors (e.g. power failure) can be handled more laxly, but still must not lead to
irreversible consequences.
Maintainability: Maintainability = suitability for debugging (localization and correction of
errors) and for modification and extension of functionality.
The maintainability of a software system depends on its:
- Readability
- Extensibility
- Testability
Readability: Readability of a software system depends on its:
- Form of representation
- Programming style
- Consistency
- Readability of the implementation programming languages
- Structuredness of the system
- Quality of the documentation
- Tools available for inspection
Extensibility: Extensibility allows required modifications at the appropriate locations to be
made without undesirable side effects. Extensibility of a software system depends on its:
- Structuredness (modularity) of the software system
- Possibilities that the implementation language provides for this purpose
- Readability (to find the appropriate location) of the code
- Availability of comprehensible program documentation
Testability: suitability for allowing the programmer to follow program execution (runtime
behavior under given conditions) and for debugging. The testability of a software system
depends on its:
Page 54 of 58
- Modularity
- Structuredness
Modular, well-structured programs prove more suitable for systematic, stepwise testing than
monolithic, unstructured programs.
Testing tools and the possibility of formulating consistency conditions (assertions) in the
source code reduce the testing effort and provide important prerequisites for the extensive,
systematic testing of all system components.
Efficiency: ability of a software system to fulfill its purpose with the best possible utilization
of all necessary resources (time, storage, transmission channels, and peripherals).
Portability: the ease with which a software system can be adapted to run on computers other
than the one for which it was designed.
The portability of a software system depends on:
- Degree of hardware independence
- Implementation language
- Extent of exploitation of specialized system functions
- Hardware properties
- Structuredness: System-dependent elements are collected in easily interchangeable program
components.
A software system can be said to be portable if the effort required for porting it proves
significantly less than the effort necessary for a new implementation.
Features of OOP
Concepts
Features of OOP
OOP stands for Object Oriented Programming and the language that support this Object
Oriented programming features is called Object oriented Programming Language. An
example of a language that support this Object oriented features is C++.
Features of Object oriented Programming
The Objects Oriented programming language supports all the features of normal
programming languages. In addition it supports some important concepts and terminology
which has made it popular among programming methodology.
The important features of Object Oriented programming are:
Inheritance
Polymorphism
Data Hiding
Encapsulation
Overloading
Reusability
Page 55 of 58
Let us see a brief overview of these important features of Object Oriented programming
But before that it is important to know some new terminologies used in Object Oriented
programming namely
Objects
Classes
Objects:
In other words object is an instance of a class.
Classes:
These contain data and functions bundled together under a unit. In other words class is a
collection of similar objects. When we define a class it just creates template or Skelton. So no
memory is created when class is created. Memory is occupied only by object.
Example:
Class classname
{
Data
Functions
};
main ( )
{
classname objectname1,objectname2,..;
}
In other words classes acts as data types for objects.
Member functions:
The functions defined inside the class as above are called member functions.
Here the concept of Data Hiding figures
Data Hiding:
This concept is the main heart of an Object oriented programming. The data is hidden inside
the class by declaring it as private inside the class. When data or functions are defined as
private it can be accessed only by the class in which it is defined. When data or functions are
defined as public then it can be accessed anywhere outside the class. Object Oriented
programming gives importance to protecting data which in any system. This is done by
declaring data as private and making it accessible only to the class in which it is defined. This
concept is called data hiding. But one can keep member functions as public.
So above class structure becomes
Example:
Class classname
{
private:
datatype data;
Page 56 of 58
public:
Member functions
};
main ( )
{
classname objectname1,objectname2,..;
}
Encapsulation:
The technical term for combining data and functions together as a bundle is encapsulation.
Inheritance:
Inheritance as the name suggests is the concept of inheriting or deriving properties of an
exiting class to get new class or classes. In other words we may have common features or
characteristics that may be needed by number of classes. So those features can be placed in a
common tree class called base class and the other classes which have these charaterisics can
take the tree class and define only the new things that they have on their own in their classes.
These classes are called derived class. The main advantage of using this concept of
inheritance in Object oriented programming is it helps in reducing the code size since the
common characteristic is placed separately called as base class and it is just referred in the
derived class. This provide the users the important usage of terminology called as reusability
Reusability:
This usage is achieved by the above explained terminology called as inheritance. Reusability
is nothing but re- usage of structure without changing the existing one but adding new
features or characteristics to it. It is very much needed for any programmers in different
situations. Reusability gives the following advantages to users
It helps in reducing the code size since classes can be just derived from existing one and one
need to add only the new features and it helps users to save their time.
For instance if there is a class defined to draw different graphical figures say there is a user
who want to draw graphical figure and also add the features of adding color to the graphical
figure. In this scenario instead of defining a class to draw a graphical figure and coloring it
what the user can do is make use of the existing class for drawing graphical figure by
deriving the class and add new feature to the derived class namely add the feature of adding
colors to the graphical figure.
Polymorphism and Overloading:
Poly refers many. So Polymorphism as the name suggests is a certain item appearing in
different forms or ways. That is making a function or operator to act in different forms
depending on the place they are present is called Polymorphism. Overloading is a kind of
polymorphism. In other words say for instance we know that +, – operate on integer data type
and is used to perform arithmetic additions and subtractions. But operator overloading is one
in which we define new operations to these operators and make them operate on different
data types in other words overloading the existing functionality with new one. This is a very
important feature of object oriented programming methodology which extended the handling
of data type and operations.
Page 57 of 58
Thus the above given important features of object oriented programming among the
numerous features it have gives the following advantages to the programming world. The
advantages are namely
• Data Protection or security of data is achieved by concept of data hiding
• Reduces program size and saves time by the concept of reusability which is achieved by the
terminology of Inheritance
• Operators can be given new functions as per user which extends the usage.
Page 58 of 58
