Software Management

The Software Development Life Cycle (SDLC) Process is the structured approach to developing software for a system or project, sometimes called the Software Development Life Cycle (SDLC). There are several approaches (see Software Development Approaches) that can be used, including waterfall, spiral, and incremental development. These different approaches will focus the testing effort at different […]

  Standard Software-related Risks should be addressed on every program with significant software content. These are risks that can be addressed by the proper attention up front, but while such attention may reduce the level of risk, the only thing that can fully eliminate these risks is the maturing of the understanding of the system

  Lessons Learned are those experiences in the past that can be used in the future to prevent mistakes or perform a task or job better. A lesson is not learned until it is put into practice or until behavior changes. The DoD has a few sources of lessons learned for Software that can be

  Software Source Selection Consideration for Computer Systems & Software (CS&S) tasks includes: Creating CS&S Request for Proposal (RFP) content Accomplishing Software Proposal Evaluation   It’s should be the objective to select developers with sound approaches; applicable domain experience in the development of software-intensive systems; proven program management, systems engineering, and software engineering processes; and

A Software Specification Review (SSR) is conducted for each Computer Software Configuration Item (CSCI) after the System Functional Review (SFR), but prior to the initiation of preliminary design for the individual CSCI. The SSR is part of the overall systems engineering process of allocating and formally defining requirements and must occur after the system/subsystem level

The Software Development Process is the structured approach to developing software for a system or project. There are a number of approaches (see Software Development Approaches) that can be used to include waterfall, spiral and incremental development. These different approaches will focus the testing effort at different points in the development process. However, each is

  The software development process often results in software size growth due to additional decomposed and derived requirements at the lower system tiers. A typical challenge for embedded systems is that software size often grows under the radar, unconstrained, unmanaged, and unattended.  In order to combat this situation, consider establishing a software size control program.

Software Risk Estimation is one of the most significant risks faced by any weapon system program.  The ability to properly estimate software size, effort, and schedule is crucial and must be addressed by every Program Manager (PM). Visit: Software Estimation Process Consideration Visit: Estimating Reuse Feasibility The following factors contribute to software estimation risk: Ability

Software Size Estimating is an important activity in software engineering that is used to estimate the size of an application or component in order to be able to implement other program management activities such as cost estimation or schedule progress.  The software engineer is responsible for generating independent estimates of the software size throughout the

Software is addressed in the Request for Proposal (RFP) in order to solicit proposals that provide the information to support an effective Government evaluation and identification of strengths, deficiencies, uncertainties, weaknesses, and risks related to software. The sections is an RFP that should address software include: [1] Statement of Objectives (SOO) Statement of Work (SOW)

The Software Resources Data Report (SRDR) collects software metrics data to supplement actual Contractor Cost Data Reporting (CCDR) cost data to provide a better understanding and improved estimating of software-intensive programs. Cost and Software Data Reporting (CSDR) System The Cost and Software Data Reporting (CSDR) system is the primary means that DoD uses to collect

Software Metrics are a measure of some property of a piece of software or its specifications. The goal is obtaining objective, reproducible and quantifiable measurements, which may have numerous valuable applications in schedule and budget planning, cost estimation, quality assurance testing, software debugging, software performance optimization, and optimal personnel task assignments. [2] Software metrics should

  The Source Selection Evaluation Team (SSET) evaluates each offeror‘s proposal and any subsequently submitted information or proposal revisions against the solicitation requirements and evaluation criteria. The SSET evaluates the offeror‘s understanding of the software task, the viability of the proposed approach, and the offeror‘s capability and capacity to perform. In addition, the SSET identifies

Software Functional Configuration Audit (FCA) should be conducted for each Computer Software Configuration Item (CSCI) in the system. Software audits may be conducted on a single CSCI or a group of CSCIs. This audit is intended to confirm the CSCI is verified/tested relative to the allocated requirements and relevant higher-level specifications. Software FCAs also verify

  Changes to the software and hardware are inevitable throughout the life cycle to fix discrepancy reports and improve system testing and maturity. As these changes occur it is imperative that a process is documented for incorporating necessary changes for hardware and software into the computer system architecture with minimal impact to the safe operation.

There are a number of pitfalls to be avoided when contracting for software-intensive systems. For example, the failure of Government Furnished Software (GFS) could render the Government responsible for subsequent failures on the part of the contractor. Another example is applying an improper type of contract for software development. Yet another is the establishment of

The software estimating process consists of a series of activities that include estimating the size of the software to be developed, modified, or reused; applying estimating models and techniques; and analyzing, crosschecking, and reporting the results. The following steps should be considered as part of any Software Size Estimating process: [1] Develop a notional architecture

Software Critical Design Review (CDR) should be performed at the Computer Software Configuration Item (CSCI) level for software-intensive systems. The primary purpose of the software CSCI CDR is to determine if the completed detailed design meets the specified requirements established in the pertinent developmental baseline (functional/performance) specification, and the design is complete and ready to

Modifying the core code of a Commercial off-the-Shelf (COTS) product should be avoided. It is possible to add code to the existing product to make it operate in a way it was not intended to do “out-of-the-box.” This, however, significantly increases program and total life-cycle costs and turns a commercial product into a DoD-unique product.

Software Assurance (SwA) is the justified confidence that the software functions as intended and is free of exploitable vulnerabilities, either intentionally or unintentionally designed or inserted as part of the system at any time during the lifecycle. Definition: Software Assurance is the level of confidence that software is free from vulnerabilities, either intentionally designed into

When a programming language decision must be made, programs should conduct a trade study to determine the best computer programming language, or mix of programming languages, to be used to satisfy system life cycle requirements. This includes the necessary criteria for Post Development Software Support (PDSS). Suggested areas to be addressed include: [1] Language supports

  Software baseline instability has done more to undermine acquisition credibility and complicate effective management of the acquisition of software-intensive systems than the inability to establish realistic software development cost and schedule baselines (Acquisition Program Baseline, Performance Measurement Baseline (PMB), and Technical Baseline). Without a realistic estimate of the required effort and schedule, tied to

Anti-Tamper (AT) is are measures that are intended to prevent and/or delay the exploitation of critical technologies in systems, training devices, and maintenance support equipment. AT measures are developed and implemented to protect Critical Program Information (CPI) in U.S. defense systems developed using co-development agreements; sold to foreign governments; or no longer within U.S. control.

Risk is a potential (uncertain) future event that has negative consequences (See Risk Management Overview). In acquisition, the risk event or consequence is often related to not achieving program objectives. Risk Management is the art or practice of controlling risk, by identifying and tracking risk areas, performing periodic risk assessments to determine risks and their

Non-Developmental Software (NDS) is any software that is not legacy software for the program, or is not developed as part of the effort being accomplished by the developer team. NDS includes: [1] Commercial off the Self (COTS) software Government Furnished Software (GFS) Open Source Software (OSS) Software being reused from another program NDS can provide