Glossary of Terms

The ilionx Architecture Design Method

System Development Methodology

Any document (physical or electronic) that persists after the project is completed. Artifacts include items delivered to the customer (project plans, requirements, etc.) as well as items used internally (design documentation, etc.)

Items created in the development process that are built for the customer. Deliverables are defined by the team and are different for each team. Examples include source code (and associated features), users manuals, etc.

(also known as metrics) The collection of numeric assessments of a project’s success. Project success should be (if at all possible) stated in terms of objective, measurable goals that leave no room for interpretation. For instance, a project measurement could be the number of defects found after release of the product. Methodology: A set of standards or protocols to follow when developing software. Typically, the methodology will include an SDLC and associated practices for each phase. Methodologies are also defined in terms of their "weight". That is, heavyweight methodologies require much documentation and ceremony. Whereas, lightweight methodologies require little documentation and ceremony outside of writing the code

The process of risk assessment in software projects is the act of finding all possible things that could go wrong with a project during its development and deployment. The process of keeping these risks from occurring, or minimizing the impact of a risk that does occur is risk mitigation.

What features are in the project (as opposed to those that are out of the project). The scope defines the boundaries of the work that will be done on the project.

The phases a software development project will go through from inception of the project to completion.

Members of the company (or sometimes outside the company) that have a stake in the outcome of the project. Frequently stakeholders are senior staff members who are responsible for large parts of the company. Additionally, stakeholders might be those in departments who are affected by the work of the department the project is serving.

In this methodology handbook, we are using the term task to denote anything the project team must do throughout the cycle of development that doesn’t necessarily yield an artifact or deliverable. Sometimes these tasks become an input to an artifact (e.g. developing a Rough Draft of Schedule becomes an input to the Project Plan). Many times, it is something that just creates value for the team that doesn’t need documented (e.g. Peer Reviews or User Department Observation.

The part of the software system that the user interacts with. This could be a web page, an RPG program, or a windows application. The distinction is made between this user interface and the application logic that goes on "behind the scenes"

DISC assessments are behavioral self-assessment tools based on psychologist William Moulton Marston’s DISC emotional and behavioral theory, first published in 1928. https://en.wikipedia.org/wiki/DISC_assessment