Software Project Documentation

Types of Project Documents  Project Charter  Requirements  Mockups and Prototypes  Test Cases  Architecture / Design Documents  Environment Diagrams  Security Model  Implementation / Support Documentation

Documents  The type of software methodology used will determine the quantity and quality of project documentation  Agile processes tend to have documentation generated as you go with final documents being delivered at the end  Traditional models (Waterfall/Spiral) require more initial documentation at early stages  Project teams also dictate the amount of documentation required

Project Charter  Statement of scope, objectives and participants in a project  One of the first documents to be generated  Goals  Identifies roles and responsibilities  Outlines project objectives  Identifies main stakeholders  Defines authority of the project manager  Serves as a reference of authority for the future of the project

Purpose of charter  Identify reasons for undertaking the project  Objectives and constraints of the project  Directions concerning the solution  Identities of main stakeholders  Identify in-scope and out of scope items  High level risk management plan  Communication plan  High level budget and spending

Three main uses of charter  To authorize the project  Serves as a primary sales document for the project  Serves as focal point throughout the project

Software Requirements Specification  These are flushed out during analysis sessions  Complete description of the behavior of a system to be developed  May include use cases which describe interactions users will have with the software  There must be a clear and thorough understanding of the product to be developed

Example of Requirements format

Mockups and Prototypes  Help to visually document ideas for user interfaces  Generally presented to the business (customers) to iron our requirements  Provide clarity on user interaction and implementation  It is cheaper and easier to do screen mockups rather than refactor completed code later on  Descriptions should accompany each screen to highlight use case features and important notes

Test Cases  Provide a concrete plan for testing the product  Ensures that the product adheres to the original requirements  Provides a repeatable way to deliver software quality  Extremely important in identifying problems as early as possible

Testing Web Applications  Areas to consider when testing web applications Functionality Testing Performance Testing Usability Testing Client Side Compatibility Security

Functionality Testing  In testing the functionality of the web sites the following should be tested: Links i. Internal Links ii. External Links iii. Mail Links iv. Broken Links  Forms i. Field validation ii. Error message for wrong input iii. Optional and Mandatory fields  Database * Testing will be done on the database integrity.  Cookies * Testing will be done on the client system side, on the temporary Internet files.

Performance  Used to determine the web site’s scalability  Used to benchmark performance  Can assist in validating third party products (e.g. servers and middleware) for potential purchase  For mobile applications, keep payloads small because of network / data constraints  Use lean data formats (e.g. json)

Usability Testing Usability testing is the process by which the human-computer interaction characteristics of a system are measured, and weaknesses are identified for correction. Ease of learning Navigation Subjective user satisfaction General appearance

Client Side Compatibility  Testing the application on various browsers  Ensuring that application renders well or is legible on smaller device form factors (mobile phones or tablets)  Ensuring javascript works across all browsers  Validation of markup, css etc

Security  The primary reason for testing the security of a web is to identify potential vulnerabilities and subsequently repair them. Network Scanning Vulnerability Scanning Password Cracking Log Review Integrity Checkers Virus Detection  Cross site scripting  SQL Injection  Denial of Service attacks

Architecture/Design  Technical detail on how system was designed  Coding specs and documentation  Document often contains the various components of the architectural view model  Good Resource  Software Architecture Document Guidelines Software Architecture Document Guidelines

Environment Diagrams  Demonstrate server and network infrastructure  Shows how traffic from external user reaches application servers and database servers  Illustrates load balancing and failover checks and balances  Shows security features such as firewalls, DMZ setup etc  Types of servers  Web (Apache, IIS, Tomcat)  Application (PHP,.NET, Ruby, Python etc)  Database (MySQL, SQL Server, Oracle, PostgreSQL)  Middleware (Java,.NET etc)

Implementation / Support  FAQs for help and troubleshooting  Tutorials and How-To guides for using the software  Problem resolution systems for bug reporting and tracking  Mechanisms for handling support (help desk, call center etc)  Documentation of scripts that have to be run nightly or batch processes to maintain data quality