S SC CH HO OO OL L O OF F I IN NF FO OR RM MA AT TI IO ON N T TE EC CH HN NO OL LO OG GY Y

MASTER OF INFORMATION TECHNOLOGY

INDIVIDUAL ASSIGNMENT
COVER PAGE

Name of Student PETER J. MAKIWA
Student Number 14299896
Name of Module LIFE CYCLE AND MATURITY MODELS FOR IT
Module Code MIT850
Name of Lecturer KATHERINE MALAN
Date of Submission 18 AUGUST 2014
Contact telephone number +263712501179
E-mail address pmakiwa@gmail.com
Declaration: I declare that this assignment, submitted by me, is my own work
and that I have referenced all the sources that I have used.
Signature of Student

Date received
Signature of Administrator

Mark
Date
Signature of Lecturer



Background
The organisation that I will be looking at is a software developing company called
Connection Software. The Company was formed in 1986 and its headquarters are
based in London. However they employ a team of carefully selected developers from all
over the world and collaboration and coordination is done online. Their core business is
developing value added SMS services with protocol conversion to corporate and non-
corporate clients found on 6 continents.
Connection software is a business to business supplier offering most of its services to
mobile network operators and large to medium sized cooperates. They pride themselves
in having a wide range of bulk SMS solutions that they deliver through PC and mobile
applications. Their products are versatile and capable of working in any language and
enable incompatible systems to interoperate. The products can also be rebranded to suit
the preferences of any corporate clients and since they have clients on almost all
continents their products can be tailor made with local content and facilities. In June
2014 alone they facilitated the delivery of SMSs in 227 countries through mobile and
satellite phones.
Some of their key corporate partners include Motorola, Vodafone, Reuters, Hewlett
Packard and British Telecom. They are a RAM Mobile Data Business Partner and have
long standing relationships with specialist providers like Page One Communications.
Clients have a choice of having a system that is fully managed by Connection software
or one where they have complete autonomy over in terms of operation but with
Connection software providing full support and maintenance or a situation where the
client operates the system completely independent of Connection software.
Product Range
Connection Software is a world renowned provider of off the shelf and tailor made SMS
products. These products include:
Mobile Messenger - This is an SMS PC application that is used to send and receive
text messages all over the world from a desktop. It is free and downloadable from their
site. It is designed for both office and home users and it integrates most of the common
address book databases. The product is re-brandable and currently Vodafone UK is
using it as a Vodafone product.

Rio - Rio is an SMS utility that can be used by corporates who intend to send
messages from numerous desktops .It is designed to offer a robust delivery system with
failsafe routing.
Drop-It This product is designed to automate text message integration with other
Microsoft applications.
Babel Box Babelbox is an off-the-shelf software thats built to link and facilitate
incompatible messaging systems.
Timbuktu Timbuktu is a redundant, fault tolerant message switch built for large
cooperates and is able to support thousands of SMSs.
SMS SDK This product is used to facilitate the smooth integration of Connection
Software's SMS service into any application development.
Hex Converter This is a product designed by Connection Software to convert a binary
file into a hex file.
In addition Connection Software also offers free source code samples and Microsoft
support files that would be valuable when developing applications using APIs.
Software Development Process
The main goals of the company for each product is to make sure that the product
behaves according to its specifications, is simple ,clear and can be maintained easily
and time and cost targets have been met.
The company uses a model that is similar to the Waterfall model and on other occasions
the Agile model especially if prototyping is required. As their primary model the waterfall
model is used on projects where the company if fairly confident of the requirements
needed to complete the task at hand. The company uses the Agile approach on projects
or works where they have a concept but have a lot more unknowns with respect to
requirements. Through rapid iterative steps that are evaluated and lessons learnt on
each pass, they get to the point where they have converted unknowns to what is known.
The agile model is used to get to a point where they acquire enough knowledge on a
task or project to then migrate to a waterfall model.
The product development or project always follows a precise working procedure or
methodology under the strict monitoring of the organisations Quality management
system.

At any given time during the development of the product high levels of confidentiality and
security are observed. Time and cost targets are always strictly adhered to and attained.
This is coordinated through frequent information exchanges and progress meetings
where the client is kept in the loop of the whole development process. The client can
also give feedback on the progress as they will have access to the companys private
extranet, where they can also report any problems that they may incur with the product.
Software Specification

1. Preliminary discussions
When developing a new product the first step that the company takes is to
critically analyse a brief that would have been given by the client and in some
cases both the company and the client will work together to produce a
comprehensive brief for the project. Requirements gathering is usually conducted
over face to face meetings with the client where an informal and relaxed
discussion is carried out with the customer on the expectations of the project. The
company can also gather requirements from existing systems, documentation
provided or analysing existing business processes if available or possible but the
meetings are always a good foundational source. Usually at this stage the
customer is often not in a position to make a commitment.

2. User Requirements Specification
Requirements engineering takes the approach of requirements identification
where the developer finds out what the clients specific requirements are,
followed by a requirements analysis and negotiation. Discussions with the client
on each requirement then follows which will include resolving requirements
conflict, drafting of requirements specification and a requirements validation
process which involves checking that requirements meet stakeholders needs.
The company also has a requirements change management process for the client
to facilitate the management of changes to requirements as the clients system is
developed. Sometimes clients will not have an idea of what their requirements
are, in part or in full and this process usually includes a variety of people namely,
the customer sales, marketing or any individuals who can contribute at this stage
and a system analyst or programmer.

The company also uses tools like Microsoft word and yED Graph to create flow
charts/use case diagrams and in some cases mind maps are also used in
requirements engineering.(Please see Apendix 1 for Requirements specification
Document)
3. Estimate:
This is not the actual quotation but a rough estimate that can help the client plan
for the resources needed for the project, its in most cases a best guess.
4. Functional Specification:
Once the customer provisionally agrees on the estimated cost the company then
produces a critical document where it contractually defines what the company
will deliver to the customer. This is usually a plain English outline or document of
what the customer requires is developed. This includes the some of the functions
and constraints that are expected from the product.(Please see Apendix 2 for
Funtional Specification Document)
5. Acceptance Test Specification
A test to verify if the requirements of the product is then done by the developer
supervised by the director of the company and is used to help validate the project.
It relies on conformance to the Functional Specification as the definition of
success.
Software Design
1. Design Specification:
At this stage the development of the functional specification is done .A design
meeting is usually conducted where documents like the acceptance test
specification, design specification and implementation specification are produced.
The functional specifications are then developed. The project milestones and
schedule area also set at this stage
Prototyping (If required)
If required a prototyping exercise may be done at this stage using the Agile
model. This stage undergoes preliminary discussions which includes all possible
iterations with each stage adding upon the last. A user requirement specification
is produced which will be sketch at best on the first iteration. A functional
specification is developed and usually this document will undergo many revisions

internally and with the customer as the unknowns are filled based on results from
iterative development steps after which development, coding and testing are done
.A document maintained by the developer detailing all progressions and practices
being applied is also developed after which peer review process is done. The
Waterfall model is usually incorporated here.
2. Quotation
After agreeing on functional specifications an accurate and precise quotation of
the project is then produced and given to the customer.
3. Contract
A contract is then drafting siting key elements like the developers duties, delivery
date, compensation, intellectual property rights, developer warranties and
specifications.
Software Implementation
1. Implementation specification:
This is intended as a full, but not tedious, definition of the detailed methods to be
used to implement a system. A Summary of the proposed Implementation
Strategy is presented and a detailed technical design is also developed.
2. Project Planning:
A project plan then follows which provides clearly defined milestones and short
term goals.
3. Coding:
Writing of the code commences at this stage. The specific languages used during
coding include C++, Microsoft Visual C++, MySQL, HTML, CSS JavaScript, Perl
Java, VB.Net, PHP and Bash Shell. The Company also uses the following
integrated development environments: Visual Studio, UNIX command line,
Dreamweaver, Komodo, Navicat for MySQL, Emacs, Eclipse and XCode. The
version tracking or version control tools that are used include Git and CVS so that
if there are any problems it is easier to go back to the preceding working version.



4. Peer Review
A Peer Review is an ongoing process that is conducted on of all aspects of the
project. This is done frequently throughout coding of a system as well as
thoroughly at the end of the coding process
Software Verification and Validation

1. Module testing
Every module that is defined in the Design Specification should be subject to
specific and exhaustive module functional tests which is the stage that follows.
The test specifications are usually generated against functional specification. This
is done by the developers or designated testers. This is white box testing. These
tests are usually for normal expected functionality, unexpected situations and how
they are handled as well as pre-condition failures. .(Please see Apendix 3 for Test
Specification Document)
2. Final integration and testing
An integration Testing process is then carried out after final integration though the
preceding extensive module testing often ensures that the product will work. This
usually includes the testing of the full system with modules installed and
integrated. Test specifications are generated against functional specification. This
is done by developers or testers. Customers may demand acceptance tests that
will need to be carried out either by the developers or the customer. These tests
are black box tests where knowledge of the internal working of the system is not
required. An evaluation of test reports is done against functional specification.
The developed system must adhere to the requirements specified in this
document
3 User documentation:
The Company then develops a user guide and support documentation
4. Installation and Upgrade Procedures are then carried out.

5. A Certificate of conformance is then issued out.(Please Apendix 4 and 5 for
Corformance Documents)


6. After delivery support strategy is then coined.
7. Post-mortem
This stage reviews the whole process for a particular project. A post-mortem
provides an opportunity to note effective and ineffective strategies with a view to
improving the companys working methods.
Tools used for collaboration and project management and review include Jitsi Microsoft
Word, Microsoft Project ,Adobe reader, Virtual box, Gpg4win, Google docs ,WunderList
,OpenVPN, Skype ,Online coding forums ,Internal Wiki ,Internal library using dewey
decimal system ,Existing code base (code libraries proprietary to us) including Secure
shell clients like ,ZOC ,Putty and Mac OSX terminal and SFTP clients , Filezilla and
CuteFTP.

See appendix for Company documents which include:
1. Requirements Specifications
2. Functional Specification
3. Testing Specification
4. Certificate of Conformance
5. Non conformity document

Gensho Client, Server & Website - Requirements Specification Issue number XXXX
This document is confidential to Connection Software Page 1 Customer number1
C:\Users\Russell\Desktop\Gensho Requirements Specification.doc Printed on : 12/08/2014 18:34:00

Gensho Client, Server & Website
Requirements Specification
1 Goal

To completely, but concisely, detail all of the missing and desirable functionality for the Gensho Client, Server and Website.
2 Client: Functionality Report
2.1 Functionality: Next Release

2.1.1 Self-Signed MIDlet Binary (MM, day)
Once we have even a self-signed MIDlet it can be trusted by the user on install so that they need never be asked again about access
to the network, file system, camera, etc.

2.1.2 File Based Persistence (MM, Specification: day?, Code: 2 days) including Offline saving of whole
Magazines (MM, see above)
The ability to write the cache, whole offline magazines, images, video, etc to the handset file system (where available).
Furthermore, the possibility (perhaps) to read files from the file system that were not written there by Gensho images, video,
ringtones, etc from the gallery.

There are two concepts here: caching and offline storage. The two are not quite the same and a document must be drawn up to
identify how each will perform the required task, and how that task meets the customers needs. . Document Complete

2.1.3 Primary to Secondary server failover (MM, Investigate: 1-2 hours)
Currently if s4 goes down, so does Gensho!

2.1.4 Test Plan Document (PB to start)
A clear, comprehensive plan for testing the client and server software.
The client will be tested on specific makes and models of handset. The tests should exercise all of the basic functionality of the
software and how it copes with error conditions (out of memory, out of storage space, broken connection). We also want to
measure the speed of the application in each case. The initial devices on test list will most likely be something like Motorola
RAZR V3, Nokia 6600/6680 and Sony Eriksson W800i to begin with.
The server tests will include stress testing and testing with multiple client connections. Both the main server (including form and
advert servers) and the push server will be tested. Complete

2.1.5 Error Log Writer Date Bug (MM)
The fast cgi component that receives log files posted from the Client does not change day and hour correctly. For instance, because
no logs were written between Monday at 20:03 and Wednesday 20:38, it simply wrote the log for Wednesday into the same log as
the Monday entry (Mon20). Complete

2.1.6 Some problems with text wrapping (PB, 1 day)
E.g. HELLO:1 on love.

Mercury Off Air Monitor - Functional Specification Page 1 Job number 1261
This document is confidential to Connection Software Customer number 1234
C:\Users\Russell\Desktop\Off Air Monitor functional spec.docPrinted on 12 August 2014

Mercury Off Air Monitor
Functional Specification
1. Document History
Author: John Coll
Version: 2
History: 18 Jun 1996 11:44 JAC 1 document created
9 July 1996 JAC 2 moved some stuff from design spec
2. Glossary
Busy Hour The hour in the day when the greatest number of pages is transmitted. This is defined by Mercury and not
calculated.
Channel Mercury sends pages over 3 Channels - each one allocated a unique transmission frequency. The Channels are
referred to as Channel 1, Channel 2 and Channel 3.
Pages A message sent to a pager.
Scribe A radio receiver that acts like a pager except that it can be configured to receive messages sent to up to 100 or
more pagers. The Scribe unit is distributed in the UK by Infostream.
Timeslot Pages are time-multiplexed within a Channel. The air-time on each Channel is divided into 8 Timeslots. Each
pager is allocated to a specific Timeslot. How this is done need not concern us here. If many pagers, or many
very active pagers were allocated to a Timeslot one might well see long delays on that Timeslot as pages are
queued for transmission.
3. Introduction
This document fully describes the functionality to be supplied to Mercury Paging and is a critical part of the contract. It is essential
that the document is complete and accurate. Connection Software will request that Mercury paging sign this Functional
Specification prior to coding to indicate that it fully specifies there requirement.
Mercury Paging wish to monitor their paging service end-to-end and this product is designed to capture and present real-life
performance data.
Mercury use 3 paging Channels and each Channel has 8 Timeslots.
Delays will be introduced to a message at many points along its path. This application is a first run at examining the delays.
Instead of initially developing an all-singing all-dancing application - which might produce little information of real value but
at high cost - it has been decided to produce a simple application and to develop it as needs emerge. That is to use iterative
stepwise refinement.
4. Overview
A linux application will be developed which will send messages over every Timeslot on every Channel. The application will
measure the Transit Time for the message from the moment it is accepted by the gateway until the Off Air Receiver receives it.
Raw log files will be stored for future analysis.
The order of transmission will be to transmit to all Timeslots on one Channel before moving to the next Channel.
Some immediate analysis will be offered by the application:
1. A screen will present the last message Transit Time for each Timeslot as a set of vertical coloured bars. This will give a clear
indication of the relative performance of each Channel/Timeslot. Marking the Timeslot bar in red will indicate exceptional
delays.
2. The Busy Hour will be defined by Mercury in the off_air.ini file .
This document is confidential to Connection Software Page 1
C:\Users\Russell\Desktop\test_plan1.doc Printed on : 12/08/2014 18:35:00

Email Gateway Stripper Module
Testing Specification
1 Document History
Author: Renato Strazzeri
Version: 1
History: 10 Oct 97 13:55 RSA 1 document created
17 Oct 97 10:22 RSA added How was it done
2 Introduction
This is the testing specification for the module Stripper of the Email Gateway system. The module stripper is
explained in the design specification. Briefly, this module receives e-mails forwarded directly by the SMTP server
and strips redundant information, producing a clean record containing the fields, From: (who send the message
truncated to a maximum of 40 characters), To: (known as ToAddress is an email address to one of the pre defined
receiver of messages), Subject: (the Pager Id or call sign) and the Message (the body text of the email, truncated to a
maximum of 240 characters). The stripper has three log files that record its activity: errorlog (includes details about
errors during processing) rejectlog (include messages that did not conform to the requirements for a message or
messages exhausted limits) and rawlog (lists all messages successfully processed used only for testing. In the final
application messages are only written in the raw log after they have been processed by the next stage as in the
application). In the final and complete system, the stripper sends messages through a TCP socket.
3 Resources
The following resources are required to perform the test:

The tests are performed in the machine named Dorothy. This is to ensure complete isolation of the test from
the normal working environment.
Three different users (email addresses simulating the systems ToAddress) must be created in Dorothy. One user
(a ToAddress) will run the application; the second user (another ToAddress) only forwards emails to the first
user. The third user runs another copy of the stripper.
A Timer server must be installed in Dorothy.
The Program ProcBytes needs to be copied to the machine Dorothy. ProcBytes requires u386mon ( a monitor
program) and nlsym (a program that creates a list of the kernel resources)
Test code, data and documentation are kept in the machine Godzilla, so it can be include in the daily backup, but
the code and the data are copied to the machine Dorothy before the test are run.
A set of good data (data that conforms to the stripper requirements) and bad data needed to be created.
To test the shared memory an executable that changes the values of the INI files and verifies if the stripper
server correctly updates the files in disk.
Certificate of Conformance



Supplier Connection Software
391 City Road
LONDON
EC1V 1NE

Certificate Serial Number 012

Certificate Date 13 September 2001

Customer Pathfinder Telecom Ltd
Shropshire House
179 Tottenham Court Road
London
W1P 9LF

Purchase Order Number PDL2001002

Software Description Operational Centre for mobile phone service

Software Version 2.03

Specification Documents
1. Specification and Quote for Pathfinder Development Ltd.,
Version 7 dated 22 Feb 2001
2. Mobile Least Cost Routing Server Specification, Version 1.2
dated 31 Jan 2001
3. System Specification for Least Cost Routing for Roaming
Mobiles, Version 1.1 dated 10 Jan 2001
4. Proposed Mobile Least Cost Routing Encryption
Mechanisms Control Centre, dated 28 December 2000
5. Mobile routing transmission protocol, Version 1.5 dated 17
May 2001
6. Change requests B2168, B2172, B2192, B2193


Certified that the software detailed here has been inspected and verified in accordance with the
conditions and requirements of the contract or purchase order and unless otherwise noted below
conform in all respects to the specifications relevant thereto.

Signed



Dated



Variations None


J1445 Eicon E1 Telephony Interface Prototype 1 - Non-Conformity Statement Page 1
Printed on : 12/08/2014 18:35:00
This document is confidential to Connection Software C:\Users\Russell\Desktop\Non-Conformity Statement.doc

J1445 Eicon E1 Telephony Interface Prototype 1
Non-Conformity Statement

1 Introduction

This document describes the areas in the development of the J1445 Eicon E1 Telephony Interface Prototype 1 (Phase
One) where there is a non-conformity issue with regard to the original functional specification.

2 Non-Conformity Issues

2.1 Terminate Call

The terminate call instruction does not identify the call to terminate. It has been assumed that this is just an oversight
and has been included, as the project cannot work without it.

The terminate call instruction includes a time to wait before processing the next instruction. This has been removed
as typo.

2.2 No URN

Where there is no URN available, the value 0 will be used.

2.3 Ring Timeout

We dont yet honour the ring timeout when making a call.

2.4 Instruction Responses

The instruction reader will do a preliminary check that the instruction is valid before passing it to the circuit
manager. This will also do some basic checking to see that the circuit and channel exist for the instruction to be
passed to. If either check fails, an error response will be returned.

Note that because of the requirement that if a call is requested on a circuit/channel that is already in use, the previous
call is terminated, an error response cannot be returned for that condition.

3 History

2006-03-22 1 MM Document Created
2006-03-27 2 MM Updated