Software Development Project Management Methodology

Brian has successfully managed software development teams and developed custom software systems professionally for over 21 years. In that time Brian has honed the methodology described below. The methodology is critical because software development is very expensive and without a proper understanding of the objectives and the problems it will solve, definately not worth the cost. Brian emphasises the importance of working directly with customers to fully describe and build a detailed understanding of how the expensive software development will pay for itself, and hopefully reallize profits many times the cost. Brian follows the methodology below because it has a series of processes and deliverables which minimize wasted efforts and maximize the chance of 100% success.

Phase 1 -Survey Project Scope and Feasibility	Deliverables
The purpose of this phase is to estimate the size and feasibility of the project. First, the Problem Statement summarizes what the customer expects the system to achieve for them from a pure business perspective. For example, the Problem Statement should describe exacly what problems the system is expected to solve. In addition the problem statement should describe how solving the problems will directly increase profits, lower costs, increase quality or speed up production. This Problem Statement should quantify the performance expectations such as how many dollars profits should increase, how many dollars costs should be lowered or how many minutes it will take for a widget to be produced after the problems are solved by the new system. Once the business problems and objectives are defined, the Scope and Feasibily Assessment examines the basic system level requirements, estimates the available resources and from that determes if the objectives are feasible with given technology and resources. Still, premature commitments to budgets, expectation and solutions shall be avoided at this stage.	Problem Statement Scope and Feasibility Assessment Project Plan
Phase 2 - Study Current System	Deliverables
The purpose of this phase is to analyze the current system. Brian recommends that adequate time is invested to study the current system, or lack of a system, to properly describe the business entities, processes and data flowing through in detail. After an understanding of the existing system, along with it's associated entities, inputs, outputs and operations is accomplished, the causes, effects, opportunities, and directives shall be addressed. The findings of the Study Phase are documented in very detailed system diagrams and descriptions which are in themselves assets which benefit the customers. Premature commitments to budgets, expectations and solutions shall be avoided at this stage.	Updated Scope and Feasibility Assessment Updated Problem Statement Updated Project Plan Overview of Existing System Existing System Architecture Diagrams Existing System Data Flow Diagrams Existing System Process Descriptions Existing System Data Dictionary Existing System Flow Charts Existing Database Entity Relatioship Diagram
Phase 3 - Propose New System	Deliverables
Once the existing system and the associated problems are understood, solutions can be explored and presented in the New System Proposal. The New System Proposal typically describes three or more solutions, one of which is the recommended solution. The New System Proposal is often accompanied by a Executive Presentation in which a prototype of the recommended solution is demonstrated if possible. Following the executive presentation, the customers are asked to select which solution is preferred. Once the solution is selected the project Budget and Resource Aquisition should be set.	New System Proposal New System Architecture Diagram Executive Presentation Budget and Resource Aquisition Updated Project Plan
Phase 4 - Requirements and Design Definition	Deliverables
In this phase the detailed requirements of the new system are written into the System Requirements Specification (SRS). These SRS is written like a users guide of the new system which describes each system feature and how the users shall interact. Once the SRS is accepted by the customers, the System Design Specification (SDS) is written. The SDS is filled with technical diagrams and descriptions of the hardware and software components of the system. The SDS shall also include a preliminary, step by step, Implementation Plan describing how, who, what, where and when the new production system is installed. The Implementation Plan may also describe running the old system and the new system in parallel for some time period. These diagrams and descritpions sometimes reveal un-foreseen expenses in the form of more specific hardware, software and resource requirements. These may prompt changes to Project Plan and Budget. In other cases, the design may answer questions which enable some costs to be reduced. Before proceeding, these Project Plan and Budget updates must be presented to the customers.	System Requirements Specification System Design Specification Implementation Plan Updated Project Plan Updated Budget and Resource Acquisition Overview of New System New System Architecture Diagrams New System Data Flow Diagrams New System Process Descriptions New System Data Dictionary New System Flow Charts New Database Entity Relatioship Diagram Requirements and Design Phase Presentation
Phase 5 - Hardware and Software Acquisition	Deliverables
Hardware and Software Acquisition usually requires purchasing Commercial Off The Shelf Software (COTS), new computer equipment, Internet domains and SSL certificates. Of course, "Cloud" venders offer other alternatives such as renting complete hosting solutions and COTS software applications. When COTS solutions fall short, customers may often recquire supplemental custom software development and database development. Brian specializes in managing teams of software developers and mentoring them through the software development process. This is accomplished by splitting the system into subsystems and assigning responsibility of the subsystems to the appropriate team members. Next, the team members are asked to produce a Subsystem Design Specification before proceding to develop the software. Brian reviews each subsystem design with the software development team. Once the software subsystems are adequately designed, the software development team is provided the Custom Software Development Process standards the team shall follow. The standards also define the use of a common Source Code Control System. Once these designs and standards are established the Software Source Code Development activities can begin.	Commecial Off the Shelf Software (COTS) Computer Equipment Internet Domains and SSL Cerificates Cloud Computer and Software Resources Custom Software Subsystem Design Specifications Custom Software Development Process Standards Source Code Control System Source Code Development Software Development Team Management Developer and Tester Job Descriptions New Developers and Testers Development Team Software Licensing Daily Development and Test Duty Matrix Administration of Cloud Services, Etc... Release Notes Standards
Phase 6 - System Testing	Deliverables
Proper System Testing is essential, with or without custom software development. The System Test Cases, derived from the System Requirements Definition, describes how to test each feature of the system and then measure the results to determine if they fall within acceptable performance parameters. These test results are described within Testing Instance Reports. Brian typically establishes the test system, installs the COTS and custom software subsystems, manages the persons who peform the tests and monitors the testing results.	System Test Cases Bug Tracking System Test Standards Test System Integration Testing Develop Training Materials
Phase 7 - System Implementation	Deliverables
Brian executes the Implementation Plan to establish the Production System and begins Production System Integration Testing AKA Alfa Testing. Once the Production System Intergration Testing is successful, the beta testing is scheduled with a select group of users.	Production System Integration Testing Production System Beta Testing Production System Rollout and Training
Phase 8 - System Sustainment and Operations	Deliverables
Production system sustainment usually requires sofware development to continue, but not with a traditional sofware development life cycle with long design, develop, release cycles. Rather, once the system is in production, Brian switches the developers and testers to a faster "Continuous Release" process. This process provides for incremental changes to the system, often on a daily basis. This proces shortens the design, develop, test and release cycle to provide a responsive system which progress rapidly.	Continuous Release Procedures Administrator / Operator Training Materials Operators Duty Matrix Operators Job Descriptions Hire and Train Operators