Logo PoisedSolutions
Home Services Client About Register Login Links Contact
Cookie Not Set
Web Development Application Development Software Analysis System Configuration Network Configuration Security

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 Managment services:

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 preideas 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.

Brainstorm Example

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.

Mind Map Example

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 diagraming. 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 diagraming 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 overiew.

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 diagraming, often low fidelity interfaces can be mocked up. The main functions of the system can be also identified and diagramed.

Poised Solutions uses the following diagraming styles:

Flow charting is one of the oldest forms of diagraming in IT and it remains effective today. The main use is in describing process flow and decision making.

Flowchart Example

UML (Universal Modeling Language) works well in an object orientated environment. UML covers a lot of different diagram strcutures, it is evolving and is a good standard to use for most project modeling.

UML Example

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-Fi), 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.

Freeform Iconographic diagrams tend to be higher level diagrams, often aesthetic and some care is taken to choosing appropriate imagery.

Poised Solutions uses the following diagraming 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, ande 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 waht 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 moreso 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 existance. 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 it helps in selection of the technical platform that will be used.

For example, in a web application you will want to test the templating engine, the form processing and database connectivity early on. Common interface layouts need to tested as well. This is the time to do all this.

To hire Poised Solutions to prototype software for your project, please get in contact, via the contact page.

Technical Requirements

Technical requirements will be built up as the analysis is underway. It is important not to be too wed to any particular platform at the start, but by the end of the analysis you have to be very sure on the technical platform.

The main areas to cover in the technical requirements are:

Programming Languages

Sometimes language selection is quite easy assuming a team of developers with varied experience.

Perl is an excellent language for text manipulation, the regular expression syntax is built into the language.

Shell scripting languages such as BASH, ZSH, KSH are great when you wish to combine programs together for administrative tasks.

Python is a great all rounder, useful as a scripting system above C/C++ libraries, prototyping tool, and for extensions to existing programs. Code tends to be very clean and succinct. And python is cross platform.

C has great performance, and has access to computer hardware directly.

C++ is a good language for creating libraries of basic functions for use by higher level languages.

Lisp and Haskell are good for AI systems.

The Java applet is supported in most browsers.

Performance is always an issue but it can be addressed in a number of ways:

Often language selection will be made by the team of developers available to work on the project, most languages are versatile, though care should be taken to ensure the language is appropriate for the project.

Thought should be given to the maintenance stage of a project as well. Selecting a well supported clean language helps when modification to the live system is required.

Libraries

A good selection of well written and supported libraries helps smooth the development process.

All libraries to be used should be listed and care taken to ensure they are robust enough for the project.

At times libraries can have a detrimental effect on the project so they should not be looked on as a panacea.

Data storage mechanisms

The main databases Poised Solutions develops for are:

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 databse 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 the personal preference of the developer, though certain IDEs can work well in team environments.

The build tool is an important tool in keeping an overview of the project. Most build tools will list all files that are used to build the project and this gives a good indication of the state of a project at any given time.

A project overview tool is useful as well, this should store all the documentation associated with the project.

Hardware

In a server based application, a development / staging environment, and a live environment is normally required. This allows code to be developed whilst the application is being used. The two environments should be fairly close to each other if not identical in specification.

The server either sources expensive parts that have a low failure rate, or generic (X86) at a high level is selected with replacement parts. Drives should generally be SCSI and RAID arrayed for performance and fault tolerance.

Unless the server is to be used for graphical processing there is little need to specify a high end graphics card for the server. Once in situ the server should probably run without a monitor.

High main memory with high CPU cache memory along with fast CPUs should be installed in the server. If everything remains in main memory whilst accessing by the clients, speed is drastically improved over accessing the drives.

A just below average host will be required for testing, this allows you to realize what it is like at the low end of the scale. The development machines and designer machines should be highly specified (one off the current top specification is a good rule of thumb) you want to waste as little time waiting on machines in the development and design process.

Most development stations should be dual headed, this allows for testing of the code directly against the original code from a visual perspective, testing happens a lot faster and more regularly with a dual head display. Monitors should be LCD nowadays to increase deskspace, and lessen eye strain. High refresh rates on the monitors are also desirable to avoid headaches. Ample memory and a fast CPU is also desirable, often the development machines will be used load test the server.

You will want access to backup server, mail server, file server, and repository, it is best if these are on separate servers with failsafes between the servers (duplication in case of failure).

Adding a cd/dvd writer for developers is also a shrewd move as you will introduce another area of backup.

Keyboards and mice should be the developers' or designers' preferences, within reason. A lot of time is spent using these devices and people become very attached to certain input devices, productivity is linked to these items. You will need some backups of these devices as well.

If you can get the developers onto a mix of the platforms you wish to support this is a good idea as it will extend your testing capability. Vary the CPU, memory, videocard and soundcard manufacturer. It is surprising how many system specific bugs you will catch with this approach, and you will often find most developers have a preferred brand in each of these areas.

Assett Requirements

These are items generally falling outside the remit of the technical development team. They are integral to the live project, though they are not essential to the technical build of the project.

The assett requirements could include, though not limited to:

It is advisable to get these assetts earlier than later on in the process, they often have a bearing on the actual release date of the project.

Test Requirements

Test cases should be devised that determine if a section of functionality is work as expected. Once the functionality passes the tests set for it, then that functionality can be marked as complete.

It is useful to have inhouse development testing criteria, per module testing, and client acceptance testing.

Test on a varied number of hosts, the test bed should include all the platforms you intend to support.

If you would like Poised Solutions to generate test cases for your software please get in contact via the contact page

Mile Stoning

Once project management, development and design have a clear picture of the project, it is advisable to set goals for deliverables. This makes the project goal driven, and gives a target to reach, in a realistic time frame.

Timings from the prototyping stage can be used to help determine times for each mile stone. Time should be allowed for testing and for bug fixing.

Gant charts are the prefered way of displaying timings and the use of Critical Path Analysis should be employed. To determine the CPA though will often require the input of key people on the project

The use of time padding is often advisiable 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 accomodate added functionality. Scope creep occuring 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 immediatley, if there is a dedicated documentor 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 personell 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 inline.

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 methodolgy. 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

Open Library Open Library

Software Analysis and Project Management Library


Home | Services | Client | About | Register | Login | Links | Contact
Copyright Poised Solutions 2007 © All Rights Reserved