Software Development

Software Development service for the Line of Business (LOB), Budget Formulation and Execution Manager (BFEM) defines the processes and deliverables for the following Activities.

• Project Management
  • Project planning
  • Project monitoring
  • Supplier management
  • Solicitation
  • Risk management
  • Decision analysis and resolution
    • Business Process Definition
    • Requirements development
    • Requirements management
    • Product development and support
    • Quality assurance
    • Configuration management

This document will identify example work products by activity; suggest tools used to monitor and maintain work products; identify templates for work product definition; and suggest a framework for work product location and format. The BP (Budget Productization) will use these guidelines to establish processes and products which best meet LOB needs

The procedures will be used to plan, manage, develop, test, and deploy following BFEM modules: Budget Formulation, Budget Performance Tracking, and Budget Execution as defined.

1. FemtoSoft Technologies Model (RDSM) Activities

This section describes the FemtoSoft Technologies development guidelines which will be used to provide project guidance to govern the production and maintenance of software. Many of the processes defined in this document are iterative and build experience gained during project execution. The guidelines should enable project managers to select appropriate processes for development and management based on the complexity and size of projects.

1.1 Project Management

The major work products and schedule for development will be defined in the Statement of Work (SOW), as agreed upon by the customer and the management team. Deliverables will be reviewed and monitored by the project team and customer representatives. Each deliverable identified in the SOW will be included in a Work Break down Structure (WBS) developed and maintained by the project team which will be available for review by FemtoSoft Technologies and the customer. A summary WBS may be developed for management to ensure stakeholders are informed of project progress. A descriptive project plan will identify the procedures for managing the project. R and D System have assigned a single Project manager who is responsible for the following:

1. Assign one single primary point of contact from FemtoSoft Technologies to function as the Project Manager. This person may also function in other areas but this person will be responsible for communicating with the Customer and the person is ultimately responsible for all contract deliverables.

2. The FemtoSoft Technologies Project Manager will produce a Project Plan, a formal Microsoft Word document, which defines the project scope, staff assignments and deliverables for this project. The Project Manager will also produce a MS Project time line for all deliverables of this Task.

3. The FemtoSoft Technologies Project Manager will allocate FemtoSoft Technologies staff resources and assign work task components to those staff resources as necessary to complete Task deliverables.

4. The FemtoSoft Technologies Project Manager will track hours spent by each assigned person using MS Project/Time Tracker on each Task.

5. The FemtoSoft Technologies Project Manager will publish the Microsoft Project time line, Microsoft Excel Staff Tracker and Microsoft word Project Plan on a weekly basis to the Customer point of contact.

6. The FemtoSoft Technologies Project Manager will attend all meetings deemed necessary by the Customer contact.

1.2 Project Planning

The project manager in consultation with the cu0stomer will create a descriptive Project Plan, in Word, which describes the Phases and methodology which will be used to create the deliverables identified in the SOW. The descriptive project plan should identify the approach and the development methodologies used to develop and maintain software. The project manager in consultation with the customer will select appropriate development methodology for example:

• Waterfall
• Iterative
• Spiral
• Other

To create the projects deliverables. The approach and software development models should be identified in the project plan before creation of software begins.

The project manager will also create a WBS in Microsoft Projects which identifies the tasks and deliverables for the project. The two documents will be revised and updated as the project progresses to include more detail and further refine product and phase descriptions. Policies conforming to FemtoSoft Technologies RDSM guidelines will be outlined in the descriptive project plan. The descriptive project plan should identify project reporting schedules, deliverables, and approach. The project plan may identify basic reporting procedures and establish guidelines for configuration management. The descriptive plan will be revised as necessary to govern the project and meet customer needs.

The project manager will use MS Projects to define a Work Breakdown Structure (WBS) for day to day management of the project which may be posted and available to relevant stakeholders- this may include posting documents to a project web site. A summary schedule may be created and posted to inform steering committees, stakeholders and senior management.

1.2.1 Project Monitoring and Control

The project manager will maintain a WBS in Microsoft Projects. The descriptive project plan will govern how often the WBS will be updated and reviewed. The project manager will be responsible for monitoring the deliverables identified in the SOW which will be identified as line items in the WBS. A summary WBS may be posted to a project or company website to inform the management, Customers, stakeholders and the project team of project progress.

Project Status Reports will be created weekly as defined in the SOW and descriptive project plan by the customer and project manager. Each status report will summarize project progress, identify the activities carried out in the reporting period, identify SOW deliverables completed, note meetings and presentations, and identify issues and risks. The project manager will identify billable time performed by SOW phase and may embed links to a time tracking system for review of hours billed to date. The project plan will identify where status reports will be posted for review by customer.

Costs and billable time may be tracked using TIMETRACKER. Contracted staff will use report their time electronically using Time Tracker within one day of completing work. FemtoSoft Technologies company guidelines will govern the documentation required to bill hours.

1.2.2 Risk management

Areas of risk, constraints and impediments to development of the agreed products will be identified in the descriptive project plan. Each identified area of risk will be assigned a probability and an impact in the descriptive project plan. Identified risks will be assigned the following probabilities:

• Certain- risks which are certain will be addressed in the project plan and mitigation plans will be addressed as part of the WBS. The project team will work with the customer and sponsor to mitigate these risks.

• Probable – the project team will identify when and how the risk may arise and may schedule time for changes to the project plan. If the impact of the risk is medium or high these risks will be discussed with the customer and may be raised with the sponsor.

• Unlikely- the project team may identify the risk and when it might arise in the descriptive project plan. If the risk does arise the project team will discuss the impact of risk with the customer and work with the customer to minimize impact. It may be necessary to work contracting officer to adjust the SOW, contract and WBS.

The project team will discuss certain and probable areas of risk and classify the impact of risk factors. Risks will be classified in the following manner:

• High- significantly impacts the project schedule or the ability of the project team to produce the work products identified and agreed upon in the SOW;

• Medium- impacts the schedule and delays production of deliverables agreed upon in the SOW;

• Low- delays production of work products but does not affect the overall schedule.

The project manager and customer will work together to address impacts to the schedule and address risks and may negotiate changes in the work plan and SOW.

1.2.3 Supplier Agreement Management

1.2.3.1 Solicitation

Requests for Quote (RFQ) and Requests for Information (RFI)s may be issued to vendors typically on a competitive basis. Quotes and Vendor information will be accessible to the project team and customer as defined in the project plan. The project plan will identify where the RFQs, RFIs, and vendor responses will be stored- often on the project web-site.

1.2.3.2 Contracts

The project plan will identify the location of all accepted contracts. All contacts will be made available to the customer.

1.2.4 Decision Analysis and Resolution

Day to day decision analysis will rest with the customer sponsor and project team. The project plan will identify pertinent escalation and resolution mechanisms based on customer governance.

1.3 Requirements Development

The project plan will identify the requirement gathering methods and required documentation. Requirements may be gathered iteratively and proto-typing may be used to clarify general requirements. The initiation of this process may be a Request for Quote to address specific business needs. The customer will identify the basic business requirements which should be addressed, possibly in a SOW. The project team will state their understanding of the problem and propose a series of tasks to meet the customer’s requirements. The project manager and team will establish a plan for collecting, documenting and verifying requirements in the project plan. Depending on the size of the project this may result in production of the following documentation:

• As is and To be Business Process Documents- which define the scope and business processes to be addressed by the system or project,

• Findings Documentation- identifies the main issues which require resolution for the project to succeed,

• General Requirements Document- specifies the external requirements to be addressed for agreement between the customer and project team, and

• Detailed Requirements- identify the system and interface requirements for discussion between the project team and developers.

1.3.1 Business Process Definition

The business processes supported by a system will be identified at a sufficient level of detail to establish a common understanding between the customer and R and D. For smaller projects this may occur in the SOW and project plan. Larger efforts may create a Business Process document which identifies the “As Is” and “To Be” processes supported. The documentation should identify the stake holders, scope, and responsibilities of parties involved in the process. Documentation may consist of diagrams and descriptions which identify the activities and outputs of each process supported or affected.

1.3.2 Requirements Management

Project plans will identify procedures for capturing, documenting, and monitoring requirements. This may include production and review of a business process document, development and agreement on a general requirements document, development of system requirements as input to design; proto-typing, documenting system incident reports (SIR), classification of system incidents into system error reports (SER), and documenting change requests. It is expected that production SIRs will be tracked using “Bugzilla”. The requirements will be used to establish a test plan and may be used to establish test cases in that plan.

1.4 Product Development

The project plan will identify the development methodology which will be used to create software and maintain systems for each phase and product developed. Common methodologies include:

• Waterfall

• Spiral

• Evolutionary

• Incremental

• Iterative

Combinations and variations of methodologies may be used where appropriate. Deviations from planned methodologies should be documented in the project plan and or status reports and agreed upon with customers. The project plan will establish documentation requirements which identify the following technical components:

• Product architecture description

  • Product component descriptions

  • Key product characteristics

  • Required physical characteristics and constraints

  • Interface requirements

  • Conditions of use (environments) and operating/usage scenarios, modes and states for operations, support, training, manufacturing, disposal, and verifications throughout the life of the product

  • Rationale for decisions and characteristics (requirements, requirement allocations, and design choices)

  • Materials requirements (bills of material and material characteristics)

  • Identify installation and maintenance procedures

  • Fabrication and manufacturing requirements (for both the original equipment manufacturer and field support)

• Product-related lifecycle process descriptions, if not described as separate product components

• Allocated requirements

• The verification criteria used to ensure that requirements have been achieved

1.5 Quality assurance

Project managers will consider the scope and work products required by the project when defining quality assurance tasks in the project plan. Project managers may define quality assurance mechanisms for each work product and a plan to ensure products conform to customer requirements. These may range from informal to formal and may include:

• Peer review of work products

• Unit testing by developers

• System Testing by developers and users

• Acceptance testing by customers

• Customer review of work products

• Requirements gathering sessions

• Findings review

• Development of operating guidelines

FemtoSoft Technologies have established development software development guidelines which include a Model View and Controller (MVC) design and development as described below. The application is separated into layers: presentation (UI), domain, and data access. In MVC the presentation layer is further separated into View and Controller.

The model layer defines the meaning of the information presented. It may include the data schema, processing algorithms. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model.

The View layer renders the model into a form suitable for interaction, typically a user interface element. MVC is often seen in web applications, where the view is the HTML page and the model layer transmits information for display to the dynamic data page.

The Controller layer processes and responds to events, typically user actions, and may invoke changes on the model. This layer may invoke identification and authorization to establish credentials for access.

Though MVC can be implemented in different ways, control flow generally works as follows:

1. The user interacts with the user interface in some way (e.g., user presses a button)

2. A controller handles the input event from the user interface, often via a registered handler or callback.

3. The controller accesses the model, possibly updating it in a way appropriate to the user's action (e.g., controller establishes the user's credentials.

4. A view uses the model to generate an appropriate user interface (e.g., view produces a screen listing the shopping cart contents). The view gets its own data from the model. The model has no direct knowledge of the view. Can be used to allow the model to indirectly notify interested parties – potentially including views – of a change.)

5. The user interface waits for further user interactions, which begins the cycle anew.

FemtoSoft Technologies has established naming and using a, naming and coding guidelines which should be adhered to by project teams when creating and supporting software.

1.6 Product Support

In consultation with the customer each project may establish a product support policy and a Concept of Operations for supported products. The Operations Guide should establish support parameters including hours of support, system incident reporting procedures, change request procedures, sign-off procedures, and changes to scope for enhancements. The products identified in the statement of work will frame the scope of the product supported.

1.7 Program Design Patterns

FemtoSoft Technologies typically develop Web based applications. In doing so FemtoSoft Technologies developers must endeavor to write software products following common design patterns as defined by Sun in their overview of patterns most importantly, FemtoSoft Technologies must employ the Model View Controller pattern when developing web based applications. The following diagram from Sun briefly describes this pattern.

1.8 Configuration management

Each FemtoSoft Technologies Project will establish a work product configuration plan to maintain deliverables for the customer and for use by FemtoSoft Technologies staff. The project plan should designate where work products will be stored and how they can be accessed. Examples of work products that may be placed under configuration management include the following:

• Plans

• Process descriptions

• Requirements

• Design data

• Drawings

• Product specifications

• Code

• Compilers

• Product data files

• Product technical publications