
Software Analysis and Project Management
Poised Solutions offers a number of Software Analysis
services to help give projects definition and momentum.
Poised Solutions is happy to take a project from
conception to delivery, acting in a analyst, project manager
or developer role.
Poised Solutions offers the following Analysis and Project
Management services:
- Software and user documentation.
- Formal Methods based specification.
- Initial Analysis generating a general specification.
- Project management through the full development life
cycle.
If you are interested in hiring
Poised Solutions for any of the above services, please get in contact, via the contact page.
Brainstorming
Brainstorming is a powerful technique to get most of the
ideas about a particular project out in the open. No idea is
rejected in the brainstorm, and as many people as possible
who will be affected by the software system should
participate.
Ideas are often linked together in succession, so some pre
thinking should be given to help keep the flow of ideas in
the broad spectrum. Only a few need to prepare though, and
the pre-ideas need only be broad, primarily designed to take
people down different avenues or ensure critical ideas are
addressed.
Every idea in the brainstorm is probably not going to be
included in the final analysis. So, it is important to keep
those who participated in the loop at least.
If you wish Poised Solutions to hold brainstorming
sessions online or at your offices, please get in contact, via the contact page.
Mind Mapping
This is normally derived from the brainstorm, but not
necessarily. This can be a solo activity or involve a
smaller number of key people.
The central idea is mapped to the center of a page. From
there any ideas that are connected are joined and any ideas
connected with that idea are joined, and so on.
The project is starting to take shape at this stage, though
the mind map may have to go through a number of iterations
involving clarification, addition and removal of ideas.
Ballpark timings and costings can start to be applied to
the different sections, to help give a general feel as to
the financial scope of the project.
If you would like Poised Solutions to produce mind maps for your software
project, please get in contact, via the contact page.
Diagramming
A lot of people like diagrams, they act as memory cues and
appeal to the aesthetic nature in us.
The BrainStorm and MindMap are both diagrams, but are more
textual diagramming. The MindMap can include pictorial
triggers though that help the retention of information.
This stage though is more involved with giving meaning to
symbols, and it further refines the project by doing so.
There are number of different diagramming styles, and it
often depends upon the project domain which will be used.
More than one diagram may be generated, and it is often
helpful to make an overview diagram and then subsequent
diagrams off that overview.
It is important not to get to wrapped up in the semantics
of any one style too much, the premise of a diagram is to
relay accurate information fast, and at times this may mean
the merging of styles. The diagram should be explained or
redesigned if there is a level of ambiguity.
The user interface is a prime candidate for diagramming,
often low fidelity interfaces can be mocked up. The main
functions of the system can be also identified and
diagrammed.
Poised Solutions uses the following diagramming styles:
- Flow charting
- Free form Iconographic.
- HTML Interface Mock-ups
- Page Identification of Interface
- UML (Universal Modeling Language)
- Graphical Image Interface Mockups
Flow charting is one of the oldest forms of diagramming in
IT and it remains effective today. The main use is in
describing process flow and decision making.
UML (Universal Modeling Language) works well in an object
orientated environment. UML covers a lot of different
diagram structures, it is evolving and is a good standard to
use for most project modeling.
Page Identification of Interface, this is a diagram of the
titles' of the screens the user will encounter when using
the application.
HTML Interface Mockups are very fast to put together.
These normally form prototypes of web applications.
Graphical Image Interface Mockups (often termed Lo-Fis),
are generally very fast to create for most graphical
designers. Only salient features are included, but the look
and feel of the application is born here.
Free form Iconographic diagrams tend to be higher level
diagrams, often aesthetic and some care is taken to choosing
appropriate imagery.
Poised Solutions uses the following diagramming
software:
If you would like to contract Poised
Solutions to build some diagrams for your software
project, please get in contact, via the contact page.
Data and Object Identification
This technique is very valuable to the final analysis.
This is where all the data items and objects are listed.
This section is a straightforward list of data and what it
is meant to represent. there should be no ambiguity at this
stage. This section is often the technical reference for a
developer on the project, and we are only one step away
from code here.
Naming conventions should be adhered to here, and we start
to form a list of technical requirements that are quite low
level.
Objects are data and methods combined, if a more functional
style of coding is to be adopted then a list of functions
should also be included.
This document needs to be kept up to date as the project
progresses. If there are non technical people involved in
the project (technical folks often use introspective
techniques on code to determine what is being used), and if
the team developing the project is large.
If you would like to contract Poised Solutions to identify
and document objects in your software project, please get in
contact, via the contact page.
Prototyping
Languages such as Python, Perl and Tcl offer the ability to
write useful code fast. They are suited for Rapid
Prototyping. Often people will use these languages in the
end solution, but they are valuable as Pseudo code writing
tools themselves. Python tends to shine here more so than
Perl or Tcl, as there is generally only one right way to do
something in Python.
The prototype is used to model a small though important,
perhaps often repeated section, of the project. It acts as a
proof of concept, and gives the project a fast entry into
digital existence. This help focus key people on the project
as they can now see a reality.
Prototyping can be done in any language or multiple
languages, and A database is often required, and even in
wholly client based software it often makes sense to use
something like:
If standard SQL is to be used then it makes sense to select
the database within your budget, and which the team has the
most knowledge of.
With that said, certain data is perhaps better suited with
certain databases. This avenue should be explored when the
data has been defined.
Operating System
Poised Solutions tends to develop on unix based systems,
such as:
This is especially true if the application is server based.
Unix systems tend to offer a high degree of stability,
performance, security and optimization, these factors have a
large influence on the project. Poised Solutions is happy to
create technical requirements for other operating systems
though.
The operating system selected and the version of associated
software may play a part with the operability of an
application. All these details should be documented.
The file system selected plays large part in the
performance of an application, as does any added security
layers.
Development Tools
A code repository is a good idea when more than one
developer is a working on a project. When there is just one
developer on a project then something like RCS should at
least be used.
Generally the IDE or editor is left to thee of time padding
is often advisable in the management of expectation.
Certain external elements may be very date dependant on the
state of the project (press releases, CD pressings etc. If
a mile stone is not achieved in the alloted time frame then
there has to be acceptance that the project has slipped
back, the amount of time padding is the safety net.
In the event of mile stones being achieved earlier than
expected the time padding can grow to perhaps eventually
accommodate added functionality. Scope creep occurring when
the time pad is being diminished should be avoided
though.
General Specification
The general specification is the collection of all of the
above techniques, it is the map from which the project can
be built.
Development of code really begins in earnest at this point,
how well the specification has been done will play a large
part on how well the coding goes.
Most development techniques though allow for an iterative
approach, the specification should not be seen as something
set in stone, unless a contract is formed directly around
it. The coding itself will reveal extra functionality or
flaws in the specification. There should be ways to address
the changing of the specification in manner that causes
least disruption. This balancing act is done by the project
manager often with the help of the lead developer.
As the specification changes the version should be kept
track of, and the time allocation constantly reviewed. It is
best to keep the specification in a central location, so all
involved are aware of any changes. Any affected by changes
should have a message stating the nature of the change sent
directly to them, a central location is good but people also
require direct notification.
User Documentation
It is often a good idea to start writing the user
documentation immediately, if there is a dedicated
documenter assigned to the project.
Software is primarily a tool. The users of the tool are
important, keeping the users and their requirements central
at all times is a good way to manage a project.
For intranets or client software, user documentation could
be online, sent out in book form or both.
The person writing the user documentation is also an ideal
candidate for training personnel on the use of the
software.
If you would like Poised Solutions to provide user
documentation or training for your software please get in contact via the contact page.
Software documentation
If the specification has been kept up to date throughout
the project, then that is normally enough for software
documentation.
Good use of commenting in the code falls into the software
documentation category as well.
If the specification is out of sync with the project and
this is not uncommon, then a software documentation stage,
post release can bring the specification back in-line.
To have Poised Solutions document your software please
get in contact via the contact page.
Formal Specification
Formal Specification is the mathematical proof that
software will work. The time taken to produce this
mathematical proof generally extends beyond the time taken
to fully code a project in an imperative language.
Functional languages such as Lisp, Haskell, and Gopher are
often used alongside this methodology. The primary use of
this methodology is in building bullet proof code for
critical system.
Formal methods do not protect from hardware failure, though
if the methodology is applied rigorously and the code
derived is identical in nature to the proof, software
failure is reduced to zero. Human error can still creep in
though and whilst the software may not technically error,
the intended result may not be the one that actually
occurs.
This approach is not often used for general purpose
software or business software, mainly due to time
constraints. This technique is often found though in the
medical, aerospace and military industries.
Poised Solutions does offer this as a service though for
those who are interested in please get in contact via the contact page
Software analysis has now been morphed into system analysis,
software engineering and project management. There is a lot
of good information on this page and a lot will probably be
tidied and taken to the new system analysis page.