Project Docs for Prevent HIV OK on Drupal 7

When Prevent HIV Oklahoma was first launched, its only purpose was to be used as a repository for information about a proposed update to Oklahoma's once progressive AIDS prevention education law, aptly named HIV Prevention Education for the 21st Century. To that end, it was built on top of WordPress to quickly create the resource and ease the use of the site by persons with little web publishing experience; however, after some review of the organic traffic and of the information easily available to Oklahomans, the website's purpose has been greatly broadened.

Purpose

The purpose of this repository is simple, best practices dictate that the documentation for any project should be version controlled so the evolution of a project may be evaluated, especially in the case of missed deadlines and upset stakeholders. This Git repository ("repo"), hosted by GitHub, will house all the documentation for the project itself – as opposed to the documentation for the individual software components – in a system that reviewable by the public, easily navigated by stakeholders, and is well-known by developers.

Audience

This repository has been established specifically for a number of groups:

stakeholders; including
linked organizations,
content creators, and
the management team.
developers; and
benefactors.

With that in mind, it's also being made available for public review, scrutiny, forking, and contribution.

Linked Files

[Project Charter](/Project Charter.md)

Reference materials

Project management

Software engineering

Software engineering can be divided into the following ten subdisciplines.

1. Requirements engineering

The elicitation, analysis, specification, and validation of requirements for software. The activities involved in requirements engineering vary widely, depending on the type of system being developed and the specific practices of the organization(s) involved. These may include:

[Requirements gathering] (https://en.wikipedia.org/wiki/Requirements_elicitation) or elicitation.
- Sequence of steps
  1. Identify the real problem, opportunity, or challenge.
  2. Identify the current measure(s) which show that the problem is real.
  3. Identify the goal measure(s) to show the problem has been addressed and the value of meeting it.
  4. Identify the "as-is" cause(s) of the problem, as it is the causes that must be solved, not the problem directly.
  5. Define the business "whats" that must be delivered to meet the goal measure(s).
  6. Specify a product design how to satisfy the real business requirements.
Requirements analysis and negotiation – checking requirements and resolving stakeholder conflicts.
- Identifying stakeholders
- Modeling goals
- Modeling context
- Discovering scenarios (or Use cases)
- Discovering "qualities and constraints" (Non-functional requirements)
- Modeling rationale and assumptions
- Writing definitions of terms
- Analyzing measurements (acceptance criteria)
- Analyzing priorities
Requirements specification (software requirements specification; SRS) – documenting the requirements in a requirements document.
System modeling – deriving models of the system, often using a notation such as the Unified Modeling Language (UML).
Requirements validation – checking that the documented requirements and models are consistent and meet stakeholder needs.
Requirements management – managing changes to the requirements as the system is developed and put into use

2. Software design

The process of defining the architecture, components, interfaces, and other characteristics of a system or component. It is also defined as the result of that process. Basic design principles enable the software engineer to navigate the design process.

Design prinicples
- The design process should not suffer from "tunnel vision". A good designer should consider alternative approaches, judging each based on the requirements of the problem, the resources available to do the job.
- The design should be traceable to the analysis model. Because a single element of the design model often traces to multiple requirements, it is necessary to have a means for tracking how requirements have been satisﬁed by the design model.
- The design should not reinvent the wheel. Systems are constructed using a set of design patterns, many of which have likely been encountered before. These patterns should always be chosen as an alternative to reinvention. Time is short and resources are limited! Design time should be invested in representing truly new ideas and integrating those patterns that already exist.
- The design should "minimize the intellectual distance" between the software and the problem as it exists in the real world. That is, the structure of the software design should (whenever possible) mimic the structure of the problem domain.
- The design should exhibit uniformity and integration. A design is uniform if it appears that one person developed the entire thing. Rules of style and format should be deﬁned for a design team before design work begins. A design is integrated if care is taken in deﬁning interfaces between design components.
- The design should be structured to accommodate change. The design concepts discussed in the next section enable a design to achieve this principle.
- The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. Well- designed software should never "bomb": it should be designed to accommodate unusual circumstances, and if it must terminate processing, do so in a graceful manner.
- Design is not coding, coding is not design. Even when detailed procedural designs are created for program components, the level of abstraction of the design model is higher than source code. The only design decisions made at the coding level address the small implementation details that enable the procedural design to be coded.
- The design should be assessed for quality as it is being created, not after the fact. A variety of design concepts and design measures are available to assist the designer in assessing quality.
- The design should be reviewed to minimize conceptual (semantic) errors. There is sometimes a tendency to focus on minutiae when the design is reviewed, missing the forest for the trees. A design team should ensure that major conceptual elements of the design (omissions, ambiguity, inconsistency) have been addressed before worrying about the syntax of the design model.
Design considerations
- Compatibility - The software is able to operate with other products that are designed for interoperability with another product. For example, a piece of software may be backward-compatible with an older version of itself.
- Extensibility - New capabilities can be added to the software without major changes to the underlying architecture.
- Fault-tolerance - The software is resistant to and able to recover from component failure.
- Maintainability - A measure of how easily bug fixes or functional modifications can be accomplished. High maintainability can be the product of modularity and extensibility.
- Modularity - the resulting software comprises well defined, independent components which leads to better maintainability. The components could be then implemented and tested in isolation before being integrated to form a desired software system. This allows division of work in a software development project.
- Reliability - The software is able to perform a required function under stated conditions for a specified period of time.
- Reusability - parts or all of the software can be used in other projects with no, or only slight, modification.
- Robustness - The software is able to operate under stress or tolerate unpredictable or invalid input. For example, it can be designed with a resilience to low memory conditions.
- Security - The software is able to withstand hostile acts and influences.
- Usability - The software user interface must be usable for its target user/audience. Default values for the parameters must be chosen so that they are a good choice for the majority of the users.
- Performance - The software performs its tasks within a user-acceptable time. The software does not consume too much memory.
- Portability - The usability of the same software in different environments.
- Scalability - The software adapts well to increasing data or number of users.
Design documents
- SDD - Software design description (IEEE 1016) – the SDD usually contains the following information:
  - The data design describes structures that reside within the software. Attributes and relationships between data objects dictate the choice of data structures.
  - The architecture design uses information flowing characteristics, and maps them into the program structure. The transformation mapping method is applied to exhibit distinct boundaries between incoming and outgoing data. The data flow diagrams allocate control input, processing and output along three separate modules.
  - The interface design describes internal and external program interfaces, as well as the design of human interface. Internal and external interface designs are based on the information obtained from the analysis model.
  - The procedural design describes structured programming concepts using graphical, tabular and textual notations. These design mediums enable the designer to represent procedural detail, that facilitates translation to code. This blueprint for implementation forms the basis for all subsequent software engineering work.

3. Software construction

The detailed creation of working, meaningful software through a combination of coding,verification, unit testing, integration testing, and debugging.

Software construction fundamentals
- Minimize complexity
- Anticipate change
- Construct for verification

4. Software testing

An empirical, technical investigation conducted to provide stakeholders with information about the quality of the product or service under test.

5. Software maintenance

The totality of activities required to provide cost-effective support to software.

6. Software configuration management

The identification of the configuration of a system at distinct points in time for the purpose of systematically controlling changes to the configuration, and maintaining the integrity and traceability of the configuration throughout the system life cycle. The goals of SCM are generally:

Configuration identification - Identifying configurations, configuration items and baselines.
Configuration control - Implementing a controlled change process. This is usually achieved by setting up a change control board whose primary function is to approve or reject all change requests that are sent against any baseline.
Configuration status accounting - Recording and reporting all the necessary information on the status of the development process.
Configuration auditing - Ensuring that configurations contain all their intended parts and are sound with respect to their specifying documents, including requirements, architectural specifications and user manuals.
Build management - Managing the process and tools used for builds.
Process management - Ensuring adherence to the organization's development process.
Environment management - Managing the software and hardware that host the system.
Teamwork - Facilitate team interactions related to the process.
Defect tracking - Making sure every defect has traceability back to the source.

7. Software engineering management

The application of management activities—planning, coordinating, measuring, monitoring, controlling, and reporting—to ensure that the development and maintenance of software is systematic, disciplined, and quantified.

8. Software development process

The definition, implementation, assessment, measurement, management, change, and improvement of the software life cycle process itself. Traditional methodologies such as waterfall that have distinct phases are sometimes known as software development life cycle (SDLC) methodologies, though this term could also be used more generally to refer to any methodology. A "life cycle" approach with distinct phases is in contrast to Agile approaches which define a process of iteration, but where design, construction, and deployment of different pieces can occur simultaneously.

9. Software quality management

The degree to which a set of inherent characteristics fulfills requirements.

Definitions
- The aim of Software Quality Management (SQM) is to manage the quality of software and of its development process.
- A quality product is one which meets its requirements and satisfies the user
- A quality culture is an organizational environment where quality is viewed as everyone's responsibility.
Description – computer scientist Ian Sommerville uses SQM as an umbrella-term that includes the following layers:
- Software Quality Assurance (SQA) layer - an organizational quality guide of
  - Standards, regulations, and procedures to produce, verify, evaluate and confirm work products during the software development lifecycle
  - Incorporated knowledge base of best practices
  - Off-the-shelf software tools selected to apply the above
- Software Quality Plan (SQP) layer – a project level quality plan written by each project for declaring project commitment to follow an applicable set of standards, regulations, procedures and tools during the development lifecycle. In addition, SQP should contain quality goals to be achieved, expected risks and risk management. SQP sources are derived from
  - SQA components that are adopted as is or customized to the project's needs
  - New procedures, standards and tools complementing missing or not-applicable SQA components that have been written in particular for the project, or imported from outside the organization.
- Software Quality Control (SQC) layer – ensures in-process that both SQA and SQP are being followed by the development teams. SQC activities include
  - Mentoring how to produce artifacts, such as well-defined engineering documents using standard templates
  - Mentoring how to conduct standard processes, such as quality reviews
  - Perform in-process quality reviews to verify, evaluate and confirm artifacts
  - Verify and evaluate to improve the use of methods, procedures and adopted software tools
SQM Roles
- to ensure that the required level of quality is achieved in a software product
- to encourage a company-wide "Quality Culture" where quality is viewed as everyone's responsibility
- to reduce the learning curve and help with continuity in case team members change positions within the organization
- to enable in-process fault avoidance and fault prevention through proper development

10. Software evolution

The process of developing software initially, then repeatedly updating it for various reasons. Maintainence types include:

Corrective maintenance: Reactive modification of a software product performed after delivery to correct discovered problems
Adaptive maintenance: Modification of a software product performed after delivery to keep a software product usable in a changed or changing environment
Perfective maintenance: Modification of a software product after delivery to improve performance or maintainability
Preventive maintenance: Modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults.