SOFTWARE DEVELOPMENT PLAN (SDP)

2015

SOFTWAREDEVELOPMENT PLAN(SDP)SYSTEM NAME

SOFTWARE DEVELOPMENT PLAN (SDP)FSKKP

MBER VERSION NUMBER (Example SDP ABC 2008 VERSION 1.0)i

AUTHOR NAME [Type the company name]To be submitted to the Software Planning & Requirement WorkshopBachelor of Computer Science (Software Engineering)

DOCUMENT APPROVALNameDate

Authenticated by:

Project Manager

Approved by:

Client

Software: Archiving Place: Copies Available:SOFTWARE DEVELOPMENT PLAN (SDP)FSKKP

ITEM NUMBER VERSION NUMBER (Example SDP ABC 2008 VERSION 1.0)

TABLE OF CONTENTS

DOCUMENT APPROVALiiTABLE OF CONTENTSiiiLIST OF FIGURESvLIST OF TABLESvi1.INTRODUCTION11.1PROJECT IDENTIFICATION11.2PROJECT OVERVIEW11.3PROJECT DELIVERABLES11.4REFERENCE MATERIALS12.SOFTWARE DEVELOPMENT MANAGEMENT22.1PROJECT ORGANIZATION AND RESOURCES22.1.1Project Organizational Structure22.1.2Internal Management Organizational Structure22.1.3Organizational Boundaries and Interface22.1.4Project Resources32.2PROCESS MODEL32.2.1Schedule and Gantt Chart32.3RISK MANAGEMENT32.4SECURITY AND PRIVACY32.5FORMAL REVIEWS32.6CORRECTIVE ACTION PROCESS32.7PROBLEM OR CHANGE REPORT33.SOFTWARE ENGINEERING53.1SOFTWARE ITEMS53.1.1Software Items53.1.2Hardware Items53.2SOFTWARE STANDARDS AND PROCEDURES53.2.1Software Development Methodologies53.2.2Design Standards53.2.3Coding Standards53.2.4Testing Approach53.3SOFTWARE PRODUCT EVALUATION PROCEDURES AND TOOLS53.3.1Evaluation Procedures53.3.2Evaluation Tools53.3.3Independence in Software Product Evaluation64.SOFTWARE CONFIGURATION MANAGEMENT74.1CONFIGURATION IDENTIFICATION74.1.1Developmental Configuration Identification74.1.2Identification Methods74.2CONFIGURATION CONTROL74.2.1Flow of Configuration Control74.2.2Review Procedures74.3CONFIGURATION STATUS ACCOUNTING74.4CONFIGURATION AUDITS75.NOTES8APPENDIX A Gantt chart9Appendix B Company Profile10

LIST OF FIGURESFigure 2.1: Project Organization Structure2

LIST OF TABLES

Table 2.1: Internal management Organizational Structure2

5ITEM NUMBER VERSION NUMBER (Example SDP ABC 2013 VERSION 1.0)

1.INTRODUCTION

This section should describe the project and the software product being to be built.

1.1PROJECT IDENTIFICATIONGive a full identification of the system and the software including the identification number(s), title(s) and abbreviation(s).

1.2PROJECT OVERVIEWGive a short summary of the project objectives, the software to be delivered, major activities, major deliverables, major milestones, and required resources. Describe the relationship of this project to other projects, if appropriate.

1.3PROJECT DELIVERABLESList all of the major items to be delivered to the customer (external customer, in- house user, etc.)

List the deliverables, delivery dates, delivery locations, delivery method (email, FTP, CD, etc.), and quantities necessary to satisfy the projects requirements.

Sample:

In-house user: SRS, SDD, STR, system,etc

External user : system, user manual etc

1.4REFERENCE MATERIALSList all the documents and other materials referenced in this document. This section is like the bibliography in a published book.

2.SOFTWARE DEVELOPMENT MANAGEMENT

In this section, describe the organizational structure (e.g., chain of command or management reporting structure), and responsibilities of individuals on the project.

2.1PROJECT ORGANIZATION AND RESOURCESThis section shall be divided into the following subsections to describe the project organization and the project resources of the contractor.

2.1.1Project Organizational StructureDescribe the overview of the clients softwares project organization structure

Figure 2.1: Project Organization Structure

2.1.2Internal Management Organizational StructureDescribe the internal management structure of the project. Use organizational charts or other appropriate notations to describe the lines of authority, responsibility, and communication within the project. Explain roles and responsibilities for each member.Table 2.1: Internal management Organizational Structure

2.1.3Organizational Boundaries and InterfaceDescribe the relationships between the project and each of the following organizations:

Parent organization (upper management) Customer organization (internal or external) Subcontracting organization(s) (if any) QA organization, if separate Documentation organization, if separate End-user support organization, if separate Any other organizations the project interacts with

This list should include a description of a specific person or project role that is responsible for maintaining the interface between the project and each of these other organizations.

Be sure to identify the person who has ultimate decision-making authority over the project.

2.1.4Project ResourcesDescribe the resources to be applied to the project. It shall include, as applicable: - Personnel resources, includingo The estimate staff loading for the project (number of personnel)o The breakdown of the staff loading numbers by responsibility (eg.Manager, software engineer, developer, tester, quality control and etc.)o The breakdown of the qualification and skill levels. Overview of developer facilities to be used, including geographic locations in which work will be performed, facilities to be used, and secure areas and other features of the necessary facilities. Acquirer furnished equipment, software, services, documentation, data and facilities required. Budget Allocation

2.2PROCESS MODELDescribe the projects lifecycle model (e.g., spiral model, evolutionary prototyping model, etc.) to be used.

2.2.1Schedule and Gantt Chart Schedule identifying the activities in each build and showing initiation of each activity, availability of draft and final deliverables and other milestones, and completion of each activity A Gantt chart, depicting sequential relationships and dependencies among activities and identifying those activities that impose the greatest timerestrictions on the project.

2.3RISK MANAGEMENTIdentify the major risks and corresponding strategies

2.4SECURITY AND PRIVACYDescribe how to implementing the security requirements

2.5FORMAL REVIEWSDescribe the internal procedures for preparing and conducting formal reviews.

2.6CORRECTIVE ACTION PROCESSDescribe the monitoring and controlling mechanisms would be implemented on corrective action process throughout the project.

2.7PROBLEM OR CHANGE REPORTDesign and describe the Problem Change Report form to be used. This report will be used to identify and controlling the problem changes entire the development. Items to be recorded are eg. Project name, originator, problem number, problem name, software element or document affected, origination date, category and priority, description, analyst assigned to the problem, date assigned, date completed, analysis time, recommended solution, impacts, problem status, approval of solution, follow up actions, corrector, correction date, version where corrected, correction time, description of solution implemented and so on.

3.SOFTWARE ENGINEERING

This section describes software engineering processes including the techni cal methods, tools, and techniques; major software documents; and supporting activities such as configuration management and quality assurance.

3.1SOFTWARE ITEMS3.1.1Software ItemsIdentify the details and purpose of software items to be used such as operating systems, compilers or IDE, design tools, debugging aids, and defect tracking and so on.

3.1.2Hardware ItemsIdentify the details hardware items to be used such as server and personal computer.

3.2SOFTWARE STANDARDS AND PROCEDURESDescribes the software standards and procedures to be used

3.2.1Software Development MethodologiesDescribes the development methodologies including requirements development practices, design methodologies and notations, programming language, coding standards and documentation standards,

3.2.2Design StandardsDescribes the design standards to be followed and applied

3.2.3Coding StandardsDescribes the coding standards to be followed and applied. The code shall follow at a minimum:-Naming conventions for variables, parameters, packaged, procedures, files, etc.Standards for comments of each line of code.

3.2.4Testing ApproachDescribes the testing approach to be followed and applied

3.3SOFTWARE PRODUCT EVALUATION PROCEDURES AND TOOLSDescribes the approach to be followed for software product evaluation

3.3.1Evaluation ProceduresIdentify and describes the procedure that will be used to evaluate and inspect the software and associated documentation.

3.3.2Evaluation ToolsIdentify and describes the tools that will be used in the software product inspection

3.3.3Independence in Software Product EvaluationDetail of softwares product evaluation procedures.

4.SOFTWARE CONFIGURATION MANAGEMENT

4.1CONFIGURATION IDENTIFICATION4.1.1Developmental Configuration Identification

Configuration identification refer to the activity to control the items (for example; documentation, source code, executable code and test software) that involve in the project, establish the identification schemes for the items and their versions and also establish the tools and techniques that will be used in managing those controlled items. To control the changes that occur in this project, the items that need to be changes are identified first. For this activity, project leader need to understand the software configuration items (CI) within the context of the system. Then they need to select the CIs that need to change, comes up with a strategy to label the software items and describe their relationship before identify the baseline that need to be used. One must know that software items evolve as a software project proceeds till end.

Basically, each member in the team has their own responsibility for the configuration management. Below are the summarizations of the responsibility of the member:i. Project leader has great responsibility in the project. They are responsible to detect the accurate identification of all the items that involve in the project, their status and also they need to control and monitor the progress of those items.ii. Business Analyst normally deals with the technology in solving any problems that arise during the development of the project. They also responsible to document all the project activities and quarantining that the final product contains all the solution that they discussed with the client.iii. Software Developer responsible in diagnosis, fix any problem in the system, develop and execute subsystem test plans, procedures and processes. Software Developer able to determine the priorities in the project development based on the definition of the development requirements.iv. Quality Assurance Manager needs to be able to analyze the derivation of the items and make sure each configuration is complete and correct.

The major activity that involve in the configuration identification is creating an identification scheme for the items to uniquely identify each of them. A proper configuration identification schemes is one that able to identify all the items in the project and provides traceability between the items and its configuration status information. So, all the members must ensure that the objective of the configuration identification is aligning with the project that being develop.

4.1.2Identification Methods

There is a method that is used in the process to identify the items that involve in the changes. Those items must have a unique identifier which contains the name, type and version attributes. The type field of the identifier must able to distinguish between three main types of CIs, namely source CIs, derived CIs and tools to generate derived CIs from source CIs.i. Source CIsCorrections and modification of the source code which are created by software engineers should always be done at the source level. Example of source CIs are documents and source code.

ii. Derived CIsGenerated by processed the source CIs using tools like compiler and linkers. To distinguish the changes of the CIs, version number are used. It changes when CIs change and most version number is an integer. Some configuration management system wills differentiate version and revision. Revision number is used to track minor changes that do not change the functionality in the system. Version number will consist of two numbers if this approached is used. For example, a software release might refer to as Version 2.1. As for a document, it might refer to as Issue 2 revision 1. The first mark refers to the major changes and the second mark refers to the minor changes

4.2CONFIGURATION CONTROL.

4.2.1Flow of Configuration Control The figure 4.1 shows the flow chart of the configuration control in the project.

Figure 4.1 Flow chart of configuration control

4.2.2Review Proceduresi. Changes requestThe stakeholders or client of the system that have a request for the changes of the CIs need to fill up a specified form and submit to the project manager.

ii. Changes evaluationProject manager will have to review the changes requested by the client and make evaluation about the advantages and disadvantages of the changes. All the risks or benefit will be list out before make a decision.

iii. Changes approval/rejectionBased on the evaluation of the changes of CIs requested by the client, project manager will decide if the changes are approved or not.

iv. Changes implementationIf the changes of the CIs are approved, implementation process will proceed. All the changes that occur will be documented to keep track the version number. So if any problem arises regarding the project, programmer will refer to the document based on version number.

4.3CONFIGURATION STATUS ACCOUNTINGNot Applicable

4.4CONFIGURATION AUDITSBrief, informal functional audits of in- scope work products will be held during the software testing and integration phases and findings will be documented.

5.NOTES

Provide alphabetical listing of all acronyms, abbreviations and their meanings as used in this document and a list any terms and definitions needed to understand this document.

APPENDIX A Gantt chart

Appendix B Company Profile