Agile Change Management – 1) Enables change through management of Agile adoption in policy and procedures for business, processes, IT or infrastructure; or development of complex solutions/systems; 2) Controlled Agile identification and implementation of necessary communications, management or training in alignment with required changes.

 

Agile Manifesto – Penned in 2001, The Agile Manifesto, also called the Manifesto for Agile Software Development, is a formal proclamation of four key values and 12 principles to guide an iterative and people-centric approach to software development.

 

Agile Modeling – A collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner. It is a supplement to other agile development methodologies such as Scrum, extreme programming (XP), and Rational Unified Process (RUP).

 

Agile Software Development – A methodology to iteratively develop products, based on Scrum and the subsequent Agile Manifesto for Software Development.

Accreditation – Formal declaration by an accrediting authority that a computer system is approved to operate in a particular security mode using a prescribed set of safeguards.

 

Actual Cost of Work Performed – The cost actually incurred and recorded in accomplishing the work performed within a given time period.

 

Agency Evaluation Committee – Group that follows a formal evaluation process to review and select a contractor using the previously defined evaluation method and evaluation criteria.

 

Agile Architecture – Agile architecture is a set of values and practices that advance the design and architecture of a system while implementing new business functions.

 

Agile Release Train – The Agile Release Train (ART) is a long lived team of Agile-Teams, which along with other stakeholders, develops and delivers solutions incrementally, using a series of fixed iterations within a program increment timebox.

 

Agile Teams – Agile Teams are a group of two- ten dedicated individual contributors, covering all the roles necessary to define, build, and test a quality incremental of value in an iteration.

 

Analogous Estimates – A simple estimating technique normally employed to develop early rough-order-of magnitude estimates. The central theory around analogous estimating is that project costs can be estimated by comparison to other similar type project efforts.

 

Application – A system providing a set of services to solve some specific user problem.

 

Architecture Review Board – Is accountable to the Executive Board which delegates to it the design of a coherent Enterprise Architecture and the establishment, maintenance and enforcement of Business and IT Strategy throughout an organization.

 

Architecture Runway – Existing code, components and technical infrastructure necessary to support implementation high priority, near-term features, without excessive delay and redesign.

 

Asset Management Repository – A tool that stores multiple types of information about project and/or organizational assets (elements of software and hardware).

 

Audit – A formal review of a project (or project activity) for the purpose of assessing compliance with contractual obligations.

 

Availability – The degree to which a system (or system component) is operational and accessible when required for use.

 

-B-

 

Backlog Grooming – Backlog grooming is when the product owner and the team review items on the backlog to ensure the backlog contains the appropriate items, that they are prioritized, and that the items at the top of the backlog are ready for delivery.

 

Backup – To copy software files onto a different media that can be sorted separately from the original files and used to restore the original files, if needed.

 

Baseline – A work product (such as software or documentation) that has been formally reviewed, approved, and can only be changed through formal change control procedures.

 

Budgeted Cost of Work Performed – The value of work performed expressed in terms of the approved budget assigned to that work for a schedule activity or work breakdown structure component.

 

Budgeted Cost of Work Scheduled – The authorized budget assigned to the scheduled work to be accomplished for a schedule activity or work breakdown structure component.

 

Build – An operational version of a software product incorporating a specified subset of the complete system functionality.

 

Built-in Quality – Built-in quality practices ensure that each solution element, at every increment, meets appropriate quality standards throughout development.

 

Burn Down/Burn Up Chart (Metric) – A burn down/burn up chartpan is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run chart of outstanding work. It is useful for predicting when all of the work will be completed. (see Velocity).

Business Case – A detailed description of how an investment is expected to support agency mission functions. It includes an analysis of business process performance and associated needs or problems, proposed alternative systems, assumptions, constraints, and cost-benefits analysis.

 

Business Owner – The representative who leads the organization that requires or directly benefits from the product or services being provided by the project. The Business Owner is the ultimate champion and works with the Agency CIO to appoint a Project Sponsor to represent the interest of the organization. They are responsible for the solution developed by the Agile Release Train (ART). They are key stakeholders on the ART and participate in certain events.

 

Business Process – A collection of related, structured activities or chain of events that produce a specific service or product for a particular customer or group of customers.

 

Business Process Reengineering – The redesign of an organization, culture, and business processes to achieve significant improvements in costs, time, service, and quality.

-C-

 

Cadence – Developing on cadence (Average Velocity over several iterations) is a strategy for managing the inherent variability in solution development, by making sure important events and activities on a regular, predictable schedule.

 

Capability – A Capability is a higher-level solution behavior that typically spans multiple Releases. They are sized and split into multiple features so that they can be implemented in increments.

 

Capacity – of an agile team is an important measure that should be used to inform the team how much workload it should undertake during its sprint planning meeting for an upcoming sprint.

 

Certification – Comprehensive analysis of the technical and non-technical security features and other safeguards of a system to establish the extent to which a particular system meets a set of specified security requirements.

 

Change Control – In Configuration Management, the process by which a change is proposed, evaluated, approved (or disapproved), scheduled, and tracked.

 

Change Implementation Notice – The formal Change Control Document used to report the actual implementation of a change in a system.

 

Code – To transform the system logic and data from design specifications into a programming language.

 

Commercial-off-the-shelf – Software or hardware that is complete and available for sale, lease, or license to the general public.

 

Communication Management Plan – Document that describes: the communications needs and expectations for the project, how and in what format information will be communicated, when and where each communication will be made, and who is responsible for providing each type of communication. This plan is a subsidiary of the Project Management Plan.

 

Communities of Practice – Communities of Practice (CoPs) are groups of people who have a common interest in a specific technical or business domain. They collaborate regularly to share information, improve their skills and performance and advance to general knowledge of the domain.

 

Concept Proposal – A key deliverable of Phase 1 Initiation, this document captures the analysis of a project opportunity and describes the business need or opportunity. It identifies where strategic goals are not being met or areas where mission performance needs to be improved.

 

Configuration – The functional and/or physical collection of hardware and software components as set forth in formal documentation.  Also, the requirements, design, and implementation that define a particular version of a system (or system component).

 

Configuration Control Board – The formal entity charged with the responsibility of evaluating, approving (or disapproving), and coordinating changes to hardware/software configuration items.

 

Configuration Item – An aggregation of hardware and/or software that satisfy an end-use function and is designated by the customer for configuration management; treated as a single entity in the configuration management process. A component of a system requiring control over its development throughout the life cycle of the system.

 

Configuration Management – The discipline of identifying the configuration of a hardware/software system at each life cycle phase for the purpose of controlling changes to the configuration and maintaining the integrity and traceability of the configuration through the entire life cycle.

 

Configuration Management Plan – A formal document that establishes formal configuration management practices in a systems development/maintenance project.

 

Configuration Management Repository – Controlled repository for source code.

 

Configuration Status Accounting – The recording and reporting of the information that is needed to effectively manage a configuration; including a listing of the approved configuration identification, status of proposed changes to the configuration, and the implementation status of approved changes.

 

Continuous Integration – Continuous integration is a built-in quality practice, where team members constantly integrate and verify their work, using automated build-and-test environments that quickly identify problems and defects.

Conversion – The process of converting (or exchanging) data from an existing system to another hardware or software environment.

 

Conversion Plan – A formal document that describes the strategies and approaches for converting/migrating data from an existing system to another hardware or software environment.

 

Cost-Benefit Analysis – The comparison of alternative courses of action, or alternative technical solutions, for the purpose of determining which alternative would realize the greatest cost benefit; cost-benefit analysis is also used to determine if the system development or maintenance costs still yield a benefit or if the effort should stop.

 

Cost Estimate – The process of determining the total cost associated with a software development or maintenance project, to include the effort, time, and labor required.

 

Cost of Delay – Cost of Delay is a way of sharing and understanding the impact of time against forecasted outcomes. It provides the means to calculate and compare the cost of not completing something now, by choosing to do it later.

 

Cumulative Flow Diagram – A Cumulative Flow Diagram is a tool used in queuing theory and often used as a measure of progress in Kanban. It is an area graph that depicts the quantity of work in a given state, showing arrivals, time in queue, quantity in queue, and departure.

 

Customer – The Customer is anyone who consumes the work of the value stream. Customers are in integral part of the agile development process and value stream.

 

-D-

 

Data Dictionary – A repository of information about data, such as its meaning, relationships to other data, origin, usage and format. A data dictionary manages data categories such as aliases, data elements, data records, data structure, data store, data models, data flows, data relationships, processes, functions, dynamics, size, frequency, resource consumption and other user-defined attributes. It also supports the data model as the repository of information about the data, including details on entities, their attributes, and relationships between the entities.

 

Data Model – A model that documents the business processes and underlying data by depicting the data structure, its characteristics, and the relationships between the data using graphical notation.

 

Data Retention Plan – Document that describes the project policies for data and records management.

 

Database Administrator – The person responsible for managing data at a logical level, namely data definitions, data policies and data security.

 

Database – A collection of logically related data stored together in one or more computerized files; an electronic repository of information accessible via a query language interface.

 

Defect Log – Tracks and summarizes in a tabular format defects or bugs found during testing. Defects may be documented via multiple commercially available bug tracking tools or manually in a spreadsheet.

 

Definition of Done – Completed work, as mutually agreed upon, by all parties and conforming to an organization’s standards, conventions and guidelines. The Definition of Done becomes the acceptance criteria for iteration (Sprint) stories.

 

Deliverable – A formal product that must be delivered to (and approved by) the customer; called out in the Task Order.

 

DevOps – DevOps is a mindset, culture and set of technical practices that foster communication, collaboration and close cooperation among all the professionals needed to develop, test, deploy and maintain a solution.

 

Development Team – The group of resources that produces the primary deliverables associated with the design, development and/or configuration, testing, and implementation of the product or service.

 

Disaster Recovery Plan – An IT focused plan designed to restore operability of targeted systems, applications, or a computer facility due to a natural or man-made extended interruption of an agency’s business services.

 

Disposition Plan – Identifies how the termination of the system/data will be conducted, and when, as well as the system termination date, software components to be preserved, disposition of remaining equipment, and archiving of life cycle products.

 

Document Repository – Tool for storing and managing documents.

 

-E-

 

Effectiveness – The degree to which a system’s features and capabilities meet the user’s needs.

 

Enablers – Enablers further the exploration, infrastructure, and architecture development activities needed to support future business functionality. Enablers arise from the backlog and occur at all levels of the framework where they are described as enabler portfolio epics, enabler capabilities and enabler features, or enables stories.

 

Enhancement – Maintenance performed to provide additional functional or performance requirements.

 

Enterprise – The enterprise represents the business entity that has the ultimate strategic, fiduciary and governance authority for all the development value streams that make up a portfolio.

 

Enterprise Architecture – An Enterprise Architecture (EA) is a conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives.

Epic – An Epic is a large body of work that can be broken down into a number of smaller user stories.

 

Epic Owners – In Scaled Agile Framework (SAFe 4.0), Epic Owners are responsible for coordinating portfolio epics through the portfolio Kanban system; they develop the business case and, when approved, work directly with the key stakeholders to help realize the implementation.

 

Executive Sponsor – The representative of executive management with final decision-making authority regarding scope, cost, and schedule.

 

Extreme programming (XP) – The software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels.

 

-F-

 

Fault Tolerance – The ability of a system (or system component) to continue normal operation despite the presence of hardware or software faults.

 

Feasibility – The extent to which the benefits of a new or enhanced system will exceed the total costs and also satisfies the business requirements.

 

Feasibility Study – A formal study to determine the feasibility of a proposed system (new or enhanced) in order to make a recommendation to proceed or to propose alternative solutions.

 

Feature – A Feature is a distinct element of functionality which can provide capabilities to the business.

 

Fixed-Price Contract – Contract that provides a firm price and places upon the contractor the risk and full responsibility for all costs and resulting profit or loss. This contract type provides additional incentive for the contractor to control costs and perform effectively.

 

Functionality – The relative usefulness of a functional requirement as it satisfies a business need.

 

Functional Configuration Audit – An audit to ensure that the functional requirements have been met by the delivered configuration item.

 

Functional Requirement – A requirement that specifies a function (activity or behavior, based on a business requirement) that the system (or system component) must be capable of performing.

 

Functional Requirements Document – A formal document of the business (functional) requirements of a system including, but not limited to, functional process requirements, data requirements, system interface requirements, non-functional or operational requirements, and a requirements traceability matrix; the baseline for system validation.

 

-H-

 

Hardware – The physical portion of a system (or subsystem), including the electrical components.

 

Hosting – The computer that controls communications in a network that administers a database; the computer on which a program or file is installed; a computer used to develop software intended for another computer.

 

-I-

 

Implementation – Installing and testing the final system, usually at the user (field) site; the process of installing the system.

 

mplementation Notice – Formal request for approval for system changes made during the Implementation Phase.

 

Implementation Phase – The Implementation Phase is the second phase of the Major Information Technology Project (MITDP). During the Implementation Phase agencies implement their solution in accordance with the States Software Development Life Cycle (SDLC) process, based on efforts of the Planning Phase. The approach focuses on the application of incremental and iterative solution delivery.

 

In-Process Review – Formal review conducted (usually annually) during the Operations and Maintenance Phase in which the System Manager evaluates system performance against baseline performance, user satisfaction with the system, adaptability to changing business needs, and new technologies that might improve the system. Project stakeholders may request ad hoc reviews when deemed necessary.

 

Incident Report – A document that describes an occurrence of a security incident, or a violation or imminent threat of violation of computer security policies, acceptable use of policies, or standard security practices (NIST SP800-61).

 

Independent Acceptance Testing – Acceptance testing performed conducted by persons separate from the management and operation of the investment or system.

 

Independent Security Testing – Security testing performed conducted by persons separate from the management and operation of the investment or system.

 

Independent Verification and Validation – An independent review conducted by persons separate from the management and operation of the investment or system.

 

Information System – A discrete set of information resources organized for the collection, processing, maintenance, transmission, and dissemination of information in accordance with defined procedures, whether automated or manual.

 

Information Technology – The application of engineering solutions in order to develop computer systems that process data.

 

Information Technology Architecture – The organizing logic for data, application and infrastructure, captured in a set of policies, relationships and technical choices to achieve desired business and technical standardization and integration. By providing a roadmap for infrastructure, applications and investment decisions, architecture decisions are pivotal to effective IT management and use.

 

Information Technology Master Plan – The annual State of Maryland plan that outlines state-wide information technology objectives and strategies.

 

Information Technology Project Request – The mechanism for requesting approval to begin a new project, continue an existing project, or fund a new or existing project.

 

Information Technology Solutions Request – The mechanism for collecting IT Solution Requests (ITSRs) for new projects and initiatives, and ensuring they are properly scoped as enterprise initiatives in accordance with the State ITMP.

 

Infrastructure – The operating environment (e.g. hardware, software, and communications).

 

Innovation and Planning Iteration – The Innovation and Planning Iteration (PI) occurs every Program Increments and serves multiple purposes. It acts as an estimating buffer for meeting PI objectives, as well as providing dedicated time for innovation, continuing education, and PI planning and Inspect and Adapt (I&A) events.

 

Inspect and Adapt – Inspect and Adapt (I&A) is a significant event, held at the end of each Program Increment (PI) where the current state of the solution is demonstrated and evaluated. Teams then reflect, and identify improvement backlog items via a structured, problem-solving workshop.

 

Input/Output – The process of entering information into a system (input) and its subsequent results (output). A hardware device that enables input (for example, a keyboard or card reader) and output (for example, a monitor or printer).

 

Inspection – A semiformal to formal technique in which software requirements, design, or code are examined in detail by a person or group other than the originator to detect errors.

 

Integration Testing – Testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them.

 

Integrity – The degree to which a system (or system component) prevents unauthorized access to, or modification of, computer programs or data.

 

Issue Logs – Lists of project issues and issue information such as description, date identified, corrective actions, resources assigned, etc.

 

Iterations – Iterations are standard, fixed-length timebox during which teams deliver incremental value in the form of working, tested software and systems. Iteration lengths may be chosen from one to four weeks, with two weeks being the suggested, and most common duration.

 

Iteration Execution – Iteration Execution is how agile teams manage their work throughout the iteration timebox, resulting in a high-quality, working, tested system increment. Each iteration follows a standard pattern; plan the iteration, commit to a goal and the work, execute, demonstrate the work to the key stakeholders, and hold a retrospective.

 

Iteration Planning – Iteration planning in a event at which all team members determine how much of the team backlog they can commit to deliver during an upcoming iteration. The team summaries the work as a set of committed iteration goals.

 

Iteration Retrospective – Iteration retrospective is a meeting where the team members discuss the results of the iteration, review their practices and identify ways to improve.

 

Iterative – Iterative development is a way of breaking down the software development of a large application into smaller chunks. In iterative development, feature code is designed, developed and tested in repeated cycles. 

Interface – To interact or communicate with another system (or system component). An interface can be software and/or hardware.

 

Information Technology Systems Security Certification and Accreditation (C&A) – A formal set of documents showing that the installed security safeguards for a system are adequate and work effectively.

-K-

Kanban – Kanban, meaning “visual sign” or “card” in Japanese, is a visual framework to implement Agile. It promotes small, continuous changes to your current system.

 

Kotter’s Change Model – Kotter's defined 8 step process are as follows:

-L-

 

Lean-Agile Mindset – Lean-agile mindset combines the concepts of the Agile Manifesto and Lean thinking, serving as the basis for agile principles and practices.

 

Lessons Learned – A formal or informal set of examples collected from experience (for example, experience in system development) to be used as input for future projects to know what went well and what did not; collected to assist other projects.

 

Lightweight methodology – A lightweight methodology is a software development method that has only a few rules and practices, or only ones that are easy to follow. In contrast, a complex method with many rules is considered a heavyweight methodology.

 

-M-

 

Maintenance – In software engineering, the activities required to keep a software system operational after implementation.

 

Maintenance Manual – Formal document that details effective system maintenance. Appendices might document maintenance procedures, standards, or other essential information on areas such as backup, networking and connectivity, access and authentication, cabling, and critical services.

 

Major Information Technology Development Project – Any information technology development project that meets one or more of the following criteria:

 

   (i) the significance of the project's potential benefits or risks;

   (ii) the impact of the project on the public or local governments;

   (iii) the public visibility of the project; or

   (iv) other reasons as determined by the Secretary.

 

Maryland Information Technology Non-Visual Access (MD IT NVA) Regulatory Standards – The general requirements and responsibilities for ensuring that information technologies are compliant with the regulatory requirements for nonvisual access.

 

Methodology – A set of methods, procedures, and standards that define the approach for completing a system development or maintenance project.

 

Metrics – A quantitative measure of the degree to which a system, component, or process possesses a given attribute.

 

Migration – Porting a system, subsystem, or system component to a different hardware platform.

 

Milestone – A scheduled event that is used to measure progress against a project schedule and budget. It represents a specific goal or event.

 

Minimal Viable Increment (MVI) – The epics and/or user stories associated with developing an increment of working software which has just enough value to be worth the effort of delivering it; no more and no less. While the Lean Startup definition of “Minimum Viable” is very useful when working in that mode, MVI in this document refers to increments that are of a high technical quality and meet the team’s definition of done at the release level. They are used primarily for creating a more Agile-friendly funding and investment vehicle.

 

Minimal Viable Product (MVP) – (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development.

 

Mission Goals – The goals or objectives of an organization or activity.

 

Model – A simplified representation or abstraction (for example, of a process, activity, or system) intended to explain its behavior.

 

Module – In system design, a software unit that is a logically separate part of the entire program.

-N-

 

National Institute of Standards and Technology – A federal technology agency that develops and promotes measurement, standards, and technology.

 

Net Present Value – The total present value of a time series of cash flows. It is a standard method for using the time value of money to appraise long-term projects.

 

Non-functional Requirements (NFR) – Non-functional requirements describe characteristics or specific parameters of the system and include audit, availability, capacity, performance, and security requirements. Other non-functional requirements include compliance with regulations and standards such as data retention and the Maryland Information Technology Non-Visual Access (MD IT NVA) Regulatory Standards.

 

Non-technical – Relating to agreements, conditions, and/or requirements affecting the management activities of a project.

 

Non-Value Added – Any activity that doesn't add to the market form or function of the product (things for which the customer is willing to pay) is a non-value added activity, or the "wastes" that lean seeks to eliminate.

 

-O-

 

Operations Manual – A formal document that provides a detailed operational description of the operations of the mainframe system and its interfaces.

 

Operations and Maintenance – Activities related to the performance of routine, preventive, predictive, scheduled, and unscheduled actions aimed at preventing equipment failure or decline with the goal of increasing efficiency, reliability, and safety.

-P-

 

Parametric Estimates – Estimating technique that uses a statistical relationship between historical data and other variables to calculate an estimate for activity parameters, such as scope, cost, budget and duration.

 

Phase Review – A formal review conducted during a life cycle phase; usually at the end of the phase or at the completion of a significant activity.

 

Performance Measurement – Method used to determine the success of an initiative by assessing the investment contribution to predetermined strategic goals. Measures are quantitative (e.g., staff hours saved, dollars saved, reduction in errors, etc.) or qualitative (e.g., quality of life, customer satisfaction, etc.).

 

Planning Phase – The Planning Phase is the initial phase in a Major Information Technology Project (MITDP). During the planning phase, agencies identify the business needs of the solution and plan for the implementation.

 

Post-Implementation Review – A formal evaluation of the information technology investment’s systems development effort after the system fully implemented (usually for at least six months) to determine whether the targeted outcome of the investment has been achieved.

 

Post-Implementation Review Report – Summarizes the assessment of Implementation activities at the end of the Implementation Phase.

 

Post-Termination Review – A formal review that documents the findings of the Disposition Phase Review and the lessons learned from shutting down and a archiving the terminated system; this report also identifies the repository for all archived products and documentation.

 

Post-Termination Review Report – A formal document detailing the findings of the Post-Termination Review.

 

Procedure – A series of steps (or instructions) required to perform an activity. Defines “how” to perform an activity.

 

Process – A finite series of activities as defined by its inputs, outputs, controls (for example, policy and standards), and resources needed to complete the activity. Defines “what” needs to be done.

 

Process Model – A graphical representation of a process.

 

Procurement Documents – Documents such as a Request for Proposal or a Task Order Request for Proposal distributed to elicit competitive and comprehensive offers from potential contractors for a product or service. The document specifies the scope of the desired procurement, defines the evaluation process, and delineates the deliverables and requirements associated with the project.

 

Procurement Officer – The State official responsible for planning and implementing procedures in the acquisition of goods and services.

 

Program Increment – In Scaled Agile Framework (SAFe), the Program Increment (PI) is a time box in which an Agile Release Train (ART) delivers incremental value in the form of working, tested software and systems. PIs are typically eight to twelve weeks long, and the most common pattern for a PI is four development iterations, followed by one Innovation and Planning (IP) iteration.

 

Program Increment Planning – In Scaled Agile Framework (SAFe) Program Increment Planning is a cadence-based, face to face planning event that serves as the core of the Agile Release Train (ART), aligning all the teams on the ART to a common goal in delivering iterative solutions.

 

Progressive Elaboration – A project management technique to continuously improve and detail a project plan as more specific information and more accurate estimates become available as the project progresses. The result is that plans are more accurate and complete, resulting from multiple iterations of the planning process.

 

Product – General term for an item produced as the result of a process; can be a system, subsystem, software component, or a document.

 

Product Backlog – The Product Backlog is a list of all things that needs to be done within a given project. It replaces the traditional requirements. These items can have a technical nature or can be user-centric e.g. in the form of user stories. A backlog can also be associated with a team, program, portfolio and value stream. 

 

Production – A fully documented system, built according to the SDLC, fully tested, with full functionality, accompanied by training and training materials, and with no restrictions on its distribution or duration of use.

 

Project – The complete set of activities associated with all life cycle phases needed to complete a systems development or maintenance effort from start to finish (may include hardware, software, and other components); the collective name for this set of activities. Typically a project has its own funding, cost accounting, and delivery schedule.

 

Project Charter – A key deliverable in the Planning Phase, this document formally authorizes the work to begin on a project and links the project work to the organization.

 

Project Implementation Request – Project Implementation Request (PIR) is the second step in the States IT Project Request (ITPR) process. Agencies update the ITPR for a Major IT Development Project (MITDP) to gain approval and enter the project Implementation Phase.

 

Project Management – The process of planning, organizing, staffing, directing, and controlling the development and/or maintenance of a system.

 

Project Management Plan – Document that defines the technical and management approach to carrying out the project schedule and a defined scope of work, including the project organization, resources, methods, and procedures.

 

Project Manager – The person with the overall responsibility and authority for the day-to-day activities associated with a project.

 

Project Planning Request – Project Planning Request (PPR) is the initial step in the States Information Technology Project Request (ITPR) process. Agencies submit an ITPR for a Major IT Development Project (MITDP) to gain approval and enter the project planning phase.

 

Project Sponsor – The principle authority regarding the expression of business needs, the interpretation of functional requirements language, and the mediation of issues regarding the priority, scope, and domain of the business requirement.

 

Project Staffing Estimates – A preliminary estimate of resources required to complete the project; serves as an input for the project staffing management plan.

 

Project Stakeholders – People or organizations actively involved in the project or whose interests may be positively or negatively affected by execution or completion of the project. A stakeholder may also exert influence over the project and its deliverables.

 

Prototype – A system development methodology to evaluate the design, performance, and production potential of a system concept (it is not required to exhibit all the properties of the final system).  Prototypes are installed in a laboratory setting and not in the field, nor are they available for operational use. Prototypes are maintained only long enough to establish feasibility.

 

-Q-

 

Quality – The degree to which a system, component, product, or process meets specified requirements.

 

Quality Assurance – A discipline used by project management to objectively monitor, control, and gain visibility into the development or maintenance process.

 

Quality Assurance Review – A formal review to ensure that the appropriate Quality Assurance activities have been successfully completed, held when a system is ready for implementation.

 

Quality Management Plan – A subsidiary plan to the Project Management Plan. Identifies relevant quality standards and determines how those standards will be satisfied.

 

-R-

 

RACI Chart – A matrix describing the participatory role types of various teams or people in completing tasks or deliverables for a project or business process. It is especially useful in clarifying roles and responsibilities in cross-functional/departmental projects and processes.

 

Rapid Application Development – In a RAD work pattern, the Requirements Definition and Design phases are iteratively conducted; in this process, a rough set of requirements is used to create an initial version of the system, giving user’s visibility into the look, feel, and system capabilities. User evaluation and feedback provide revisions to the requirements, and the process is repeated until the requirements are considered to be complete.

 

Records Management – The formal set of system records (for example, files, data) that must be retained during the Disposition Phase; the plan for collecting and storing these records.

 

Recoverability – The ability of a software system to continue operating despite the presence of errors.

 

Refactoring – Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

 

Regression Test – In software maintenance, the rerunning of test cases that previously executed correctly in order to detect errors introduced by the maintenance activity.

 

Release – A configuration management activity wherein a specific version of software is made available for use.

 

Release Notes – Summary information regarding the current release of the system being built; typically includes major new features and changes and identifies known problems and workarounds.

 

Release Train Engineer – The Release Train Engineer (RTE) facilitates the Agile Release Train and Solution Train processes and execution. They escalate impediments, risks and help ensure value delivery, and help drive relentless improvement. They also participate in the Lean-Agile transformation, coaching leaders, teams, and Scrum Masters in the new processes and mindsets. They help configure SAFe to the needs organization, standardizing and documenting practices; Manage and optimize the flow of value using various tools, such as the Program Level Kanban and other information sources; Establish and communicate the annual calendars and Facilitates PI Planning; and, fosters preparation of Vision, Program and Team Level Backlogs via Pre- and Post-PI Planning meetings. Facilitates the PI planning event.

 

Reliability – The ability of a system (or system component) to perform its required functions under stated conditions for a specified period of time.

 

Request for Proposal – Document to elicit competitive and comprehensive offers from potential contractors for a product or service. The document should specify the scope of the desired procurement, define the evaluation process, and delineate the deliverables and requirements associated with the project.

 

Requirement – A capability needed by a user; a condition or capability that must be met or possessed by a system (or system component) to satisfy a contract, standard, specification, or other formally imposed documents.

 

Requirements Traceability Matrix – A table that links requirements to their origins and traces them throughout the project life cycle.

 

Resource – In management, the time, staff, capital and money available to perform a service or build a product; also, an asset needed by a process step to be performed.

 

Responsibility Assignment Matrix – Defines in detail the roles, authority, responsibility, skills, and capacity requirements for all project tasks needed to complete the project. The agency and contractor responsibilities are addressed in the RAM.

 

Risk – A potential occurrence that would be detrimental to the project; risk is both the likelihood of the occurrence and the consequence of the occurrence.

 

Risk Assessment – The process of identifying areas of risk; the probability of the risk occurring, and the seriousness of its occurrence; also called risk analysis.

 

Risk Management – The identification, measurement, control, and minimization of risk in order to optimize the probability of success (that is, minimize the risk).

 

Risk Management Plan – A formal document that identifies project risks and specifies the plans to reduce these risks.

 

Roadmap – Roadmap is a plan that matches short-term and long-term business goals with specific technology solutions to help meet those goals. A roadmap is usually a graphical, high level overview presented on a timeline.

 

Rough Order of Magnitude – An estimate used when a project is in nascent, and requirements are not yet detailed.

 

-S-

 

Schedule Variance – Earned value minus the planned budget for the completed work.

 

Scope – The established boundary (or extent) of what must be accomplished; during planning, the scope defines what the project will comprise (and just as important, what the project will not comprise).

 

Scope of Work – Document that defines the project boundaries. One of the most critical parts of a procurement document, the statement of work describes, in detail, the project deliverables, deliverable requirements, and the work required to create those deliverables.

 

Scrum – A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is used in incremental agile software.

 

Scrum of Scrums – Scrum of Scrums is a framework within Scrum comprised of a hierarchical structure where multiple Scrum team representatives get together and work collaboratively on related projects in incremental agile software development.

 

Scrum Master – The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team.

 

Scrum Team – The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. Scrum Teams deliver products iteratively.

 

Security – The establishment and application of safeguards to protect data, software, and hardware from accidental or malicious modification, destruction, or disclosure. Measures and controls that ensure the confidentiality, integrity, availability, and accountability of the information processes stored by a computer.

 

Security Officer – The team member responsible for 1) monitoring the secure operations of the system and site by the business operations community, and 2) ensuring the system and site is deployed and operated according to the documented security requirements through integration of all security disciplines (Management, Operational, and Technical) to maintain an acceptable level of risk.

 

Security Plan – Plan documenting system security considerations such as access, physical or architectural modifications, and adherence to State security requirements.

 

Security Risk Assessment – Tool that permits developers to make informed decisions relating to the acceptance of identified risk exposure levels or implementation of cost-effective measures to reduce those risks. Addresses threats, vulnerabilities, risks, outcomes, and security controls. It also evaluates compliance with baseline security requirements, identifies threats and vulnerabilities, and assesses alternatives for mitigating or accepting residual risks.

 

Security Test – A formal test performed on an operational system, based on the results of the security risk assessment in order to evaluate compliance with security and data integrity guidelines, and address security backup, recovery, and audit trails.

 

Software – Computer programs (code), procedures, documentation, and data pertaining to the operation of a computer system.

 

Software-as-a-Service (SaaS) – Web-based software purchased on a subscription basis.

 

Software Development Document – Contains all of the information pertaining to the development of each unit or module, including the test cases, software, test results, approvals, and any other items that will help explain the functionality of the software.

 

Solution and Roadmap Document – The Solution and Roadmap document is a deliverable in the Planning Phase that help define objectives, features and capabilities, acceptance criteria, and Program Increment Planning estimates based upon stakeholder’s objectives. This document should be used as a baseline to further define and build upon in the light weight business case, as well as, a “go to” in evaluating if you have met your Definition of Done.

 

Solution Architect – The Solution Architect, in information technology, is a practitioner of solution architecture. Typically part of the solution development team, the solution architect translates requirements created by functional analysts into the architecture for that solution and describing it through architecture and design artifacts.

 

Solution Train Engineer – The Solutions Train Engineer (STE) facilitates the Agile Release Train and Solution Train processes and execution, the same as the RTE, however, their function is at a higher level within the enterprise, focusing on the procurement and infrastructure. They escalate impediments, risks and help ensure value delivery, and help drive relentless improvement. They also participate in the Lean-Agile transformation, coaching leaders, teams, and Scrum Masters in the new processes and mindsets. They help configure SAFe to the needs organization, standardizing and documenting practices. Manage and optimize the flow of value using various tools, such as the Program Level Kanban and other information sources., Establish and communicate the annual calendars and Facilitates PI Planning; and, fosters preparation of Vision, Program and Team Level Backlogs via Pre- and Post-PI Planning meetings. Facilitates the PI planning event.

 

Sprint – A Sprint is a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints best have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

 

Sprint Backlog – Sprint Backlog is a list of items to be executed by the Scrum Team in the upcoming Sprint.

 

Sprint Review – A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration. Timebox for the Sprint Review is four hours for a one month Sprint or shorter if the Sprint is less than one month.

 

Sprint Retrospective – The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is a three-hour time-boxed meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose.

 

Sprint Planning – The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team. Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box. 

Standard – Mandatory requirements to prescribe a disciplined uniform approach to software development and maintenance activities.

 

Standard Operating Procedures (SOPs) – Define in detail how the Operations & Maintenance (O&M) team will perform the business processes related to the maintenance O&M of the system. Whereas the User Guide is focused on the use of the system specifically, the SOP addresses all related business processes.

 

State Archivist – The Senior Manager who oversees the Maryland State Archives and is responsible for the Archive’s collection of government and private materials.

 

Story Points – Story Points are the estimates of effort required to implement a Product Backlog Item, as influenced by the amount of work, complexity, risk and uncertainty. In SAFe (Scaled Agile Framework) Story points are also used to estimate Epics and Features. Fibonacci sequence is often used to size stories because it doubles in number exponentially; IE: 0, 1/2, 1, 2, 3, 5, 8, 13 /or sometimes T-Shirt Sizes; S,M,L,XL.

 

Strategic Themes – Strategic Themes are differentiating, specific, and itemized business objectives that connect a portfolio to the strategy of the enterprise. They provide business context for decision-making, and serve as inputs to the vision, budget, and backlogs for the Portfolio, Large Solution, and Program levels. The primary purpose of strategic themes is to drive portfolio innovation and differentiation.

 

Subject Matter Expert (SME) – A person with extensive expertise in a particular area.

 

Subsystem – A collection of components that meets the definition of a system, but is considered part of a larger system.

 

System – A collection of components (hardware, software, interfaces) organized to accomplish a specific function or set of functions; generally considered to be a self-sufficient item in its intended operational use.

 

System (Application) Software – This file or set of files contains the application or software code on discs or other media.

 

System Component – Any of the discrete items that comprise a system or subsystem.

 

System Design Document – A formal document that describes the system architecture, file and database design, interfaces, and detailed hardware/software design; used as the baseline for system development. Specifies the details of the system and each system component and their interaction with each other and external systems and the interface that allows users to operate the system and its functions.

 

System Development Life Cycle (SDLC) – The SDLC is a term used in systems engineering, information systems and software engineering to describe a process for planning, creating, testing, and deploying an information system.

 

System Security Consensus Document – Single document containing all information relevant to completing the system’s Certification & Accreditation.

 

System Security Plan – A formal document that establishes the processes and procedures for identifying all areas where security could be compromised within the system (or subsystem).

 

System Testing – The process of testing an integrated hardware/software system to verify that the system meets its documented requirements, including performance requirements.

 

Systems Administration Manual – A manual, oriented toward distributed (client/server) applications that provides details about system operations.

 

System Manager – The individual, or group, responsible for post-implementation system maintenance, configuration management, change control, and release control. This may or may not include members of the development team.

 

System Software – Software designed to facilitate the operation of a computer system and associated computer programs (for example, operating systems, code compilers, utilities).

 

-T-

 

Task – In project management, the smallest unit of work subject to management accountability; a work assignment for one or more project members fulfilling a role.

 

Team Demo – Team Demo is used to measure progress and get feedback at the end of each iteration by demonstrating every story, agreed upon work and new work requested in the recent iteration. A Team Demo can be occur at the Solution level as well.

 

Technical Requirements – Description of hardware, software, and communications requirements associated with the initiative.

 

Test – The process of exercising the product to identify differences between expected and actual results and performance.  Typically testing is bottom-up: unit test, integration test, system test, and acceptance test.

 

Test Analysis Approval Determination – Summarizes the system’s perceived readiness and is attached to the Test Analysis Report as a final result of the test reviews for all testing levels above the Integration test.

 

Test Analysis Reports – Formal documentation of the software testing as defined in the Test Plan. Presents a description of the unit tests and the results mapped to the system requirements and identifies system capabilities and deficiencies.

 

Test Data – Dummy files/data, which are not live or sensitive, developed for the purpose of executing a test; becomes part of a test case.

 

Test-driven Development (TDD) – is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.

 

Team of Teams – In Scaled Agile Framework (SAFe) Team of Teams is used for scaling large software development projects, The Team of Teams (Scrum of Scrums in Scrum/Nexus Daily Scrum in Nexus) is an event in which representatives from multiple Scrum, Scrumbon or Kanban teams meet to discuss, integration progress, and resolve any intra-dependencies or impediments. Generally used in SAFe (Scaled Agile Framework). 

Test Phase – Life cycle phase during which subsystem integration, system, security, and user acceptance testing are conducted; done prior to the Implementation Phase.

 

Test Master Plan – The formal document that identifies the tasks and activities so the entire system can be adequately tested to assure a successful implementation.

 

Test Problem Reports – Document problems encountered during testing; attached to the Test Analysis Report.

 

Time and Materials Contract – Services based on direct labor hours at a fixed hourly rate, which typically includes wages, overhead, general and administrative expenses, and profit.

 

Tools – Software application products that assist in the design, development, and coding of software.

 

Traceability – In requirements management, the identification and documentation of the derivation path (upward) and allocation path (downward) of requirements in the hierarchy.

 

Training – The formal process of depicting, simulating, or portraying the operational characteristics of a system or system component in order to make someone proficient in its use.

 

Training Plan – A formal document that outlines the objectives, needs, strategy, and curriculum to be addressed for training users of the new or enhanced system.

 

Tuckman Stage – Team formation usually follows easily recognizable stages, known as "forming, storming, norming, and performing." Psychologist Bruce Tuckman, who created this memorable phrase, later added a fifth stage, "adjourning" or "mourning."

 

-U-

 

Unit – the smallest logical entity specified in the design of a software system; must be of sufficient detail to allow the code to be developed and tested independent of other units.

 

Unit/Module Testing – In testing, the process of ensuring that the software unit executes as intended; usually performed by the developer.

 

Unit and Integration Test Plans – The detailed scripts used in the Development and Test Phases for evaluating the completeness and correctness of the smallest parts of the system and the components created from those parts. The test scripts are more specific than the Test Master Plan, which is high-level and more focused on processes.

 

Upgrade – A new release of a software system for the purpose of including a new version of one or more system components.

 

Usability – The capability of the software product to be understood, used and is of value to the user under specified conditions.

 

User – An individual or organization who operates or interacts directly with the system; one who uses the services of a system. The user may or may not be the customer.

 

User Experience – User Experience relates to the interaction a user experiences when interacting with a product or service

 

User Acceptance Test – Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the user to determine whether or not to accept the system.

 

User Interface – The software, input/output devices, screens, procedures, and dialogue between the user of the system (people) and the system (or system component) itself. See Interface.

 

User Manual – Describes to end users how to make full use of the information system, including system functions and capabilities, contingencies and alternate modes of operation, and step-by-step procedures for system access and use.

 

User Story – A User Story is a tool used in agile software development to capture a description of a software feature from an end-user perspective. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement.

 

-V-

Validation – The process of determining the correctness of the final product, system, or system component with respect to the user’s requirements. Answers the question, “Am I building the right product?”

 

Variance at Completion – The difference between the total budgets assigned to a contract, WBS element, organizational entity, or cost account and the estimate at completion; represents the amount of expected overrun or under run.

 

Velocity – Velocity is a metric that predicts how much work an agile software development team can successfully complete within an iteration or specified time-boxed period. In Agile Software Development, Velocity is often calculated using Estimates and Story Points. Velocity can be tracked using a Burn Down/Up Chart (see Burn Down/Up Chart). In Kanban, Velocity is usually tracked by using a cumulative flow calculation.

 

Vision – Vision is a description, or future view of the solution to be developed, reflecting customers and stakeholder needs, as well as proposed features and capabilities. It provides the larger contextual overview and purpose of the solution under development.

 

Vision Statement – Vision Statement is a deliverable in the Planning Phase that documents the intended vision of the project, and how it will positively impacts the mission of the agency, and the citizens of Maryland. It is meant to highlight how the investment benefits the end-user.

 

Verification – The process of determining whether the products of a life cycle phase fulfill the requirements established during the previous phase; answers the question, “Am I building the product right?”

 

Version – An initial release or re-release of a computer software configuration item, associated with a complete compilation or recompilation of the computer software configuration item; sometimes called a build.

 

Version Description Document – Primary configuration control document used to track and control versions of software released to the operational environment. It also summarizes features and contents for the software build and identifies and describes the version of software delivered.

 

Value Streams – Value Streams is a fund mental thinking construct in Lean. Each Value Stream is the sequence of steps used to continuously deliver value to the Customer. It includes the whole sequence, from concept or customer order to delivery of value.

 

-W-

 

Weighted Shortest Job First (WSJF) – WSJF is specific to Scaled Agile Framework (SAFe) a prioritization model used to sequence “jobs” (e.g., Features, Capabilities, and Epics) to produce maximum economic benefit. WSJF is estimated as the cost of delay divided by job size.

 

Work Breakdown Structure – In project management, a deliverables-oriented hierarchical decomposition of the project team activities associated with developing the project objectives and required deliverables; often used to develop a Gantt chart, its development is a method used to identify, organize and define the total scope of the project.

 

Work Package – A subset of a project that can be assigned to a specific party for execution. Because of the similarity, work packages are often misidentified as projects. Estimates of Work Packages are used in Earned Value Management to calculate the Planned Value of a project. Progress made against each work package is used to calculate the Earned Value. Actual costs charged to each work package are used in variance analysis.