The page you’re looking for does not exist. It may have been moved. You can return to the start page, or follow one of the links in the navigation to the left.
+If you arrived on this page by clicking on a link, please notify the owner of the site that the link is broken. +If you typed the URL of this page manually, please double check that you entered the address correctly.
+namespace DefaultNamespace;
+
+public class SampleCode
+{
+ private readonly ILogger _logger;
+ public SampleCode(ILogger<Logger> logger)
+ {
+ _logger = logger;
+ }
+}| + + | ++This glossary is a work in progress. It does not include all the terms in XADM. + | +
The ilionx Architecture Design Method
+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
+The page you requested has been relocated to https://xadm.ilionx.com/component-xadm/0.1.0/introduction.html.
diff --git a/component-xadm/0.1.0/introduction.html b/component-xadm/0.1.0/introduction.html new file mode 100644 index 0000000..7e5f647 --- /dev/null +++ b/component-xadm/0.1.0/introduction.html @@ -0,0 +1,403 @@ + + + + + +
+ilionx architecture design method (XADM) describes project phases, processes and artefacts which are linked to ach other. +xADM decribes why to follow this process, how and what to do.
+It has been set up in a layered fashion. +Which means that at the highest level it could be adopted by a wide variety of teams in different kind of technology stacks. +The lower you descent the more specific it is tailored towards a specific technology stack. +In this case the Microsoft stack has been fully ironed out (Azure, C#.Net).
+
+| + + | ++Practice, practice, practice!!! + | +
We need to have a professional approach for delivering software projects. +By standardizing our way of working via phases, processes and artefacts, the focus is on the content, the project and solution design effort. +We facilitate on-boarding, handovers and reviews.
+Having a guided approach for software projects, eliminates a lot of hassle upfront in the project. +There is a clear script to be followed, which:
+improves estimations
+improves project execution
+improves the ability to review a project
+improves onboarding of new members
+improves predictability
+Software can be the differentiating factor for companies within their business domain. +So successful software projects can deliver great value, but unsuccessful software projects can deliver a devastating blow into the financial health of a company and the viability of the company as a whole.
+The initial trigger for xADM came from the architects (See Contributors). +Initially xADM guided the architect in going from requirements to architecture. +This is a combination of experiences of the architects and based on IDesign methods.
+Later in time the scope of xADM has been widened to also involve project phases and detailed level design.
+xADM describes project phases, processes and artefacts to be used when running a software project. +It can be used as a whole to tackle software projects but it can also be used in parts eg. only use particular processes or artefacts.
+It is still growing and it now describes what a BA does, how a UX person works, what an architect does and how all of this fits into planning and executing a software project. +All these roles have a particular part to fulfill before development can start developing.
+There is also a technical part described in xADM that supports the method on the technical side. +This framework is called Copper. +It implements the reference architecture and covers a lot of the non functional requirements out-of-the-box. +Using Copper is not a must but will significantly speed-up development and the maturity of the product.
+| Name | +Role | +Specialism | +Aka | +
|---|---|---|---|
Wouter Roos |
+Architect |
+WCF, API, Tooling, Azure |
+Toolboy |
+
Bart Bovend’eerdt |
+Architect |
+Service fabric, Azure |
+Copper |
+
Rob Hodzelmans |
+Architect |
+Project quotation, … |
++ |
Koen Mannaerts |
+Architect |
+Project design |
++ |
We hebben een applicatie gebouwd maar zien problemen opduiken: performance, integratie, onderhoudbaarheid. Hoe beginnen?
+We zijn al jaren aan het bouwen en hebben tig applicaties maar alles staat los van elkaar en willen integreren. Maar dit lukt ons niet. Hoe verder?
+We zijn al voor de 2,3de, 4de keer gestart met bouwen maar het is telkens mislukt. We willen nu even goed nadenken voor we beginnen. Kan je ons helpen?
+We hebben een bestaand landschap maar dit ondersteunt onze huidige business expansie niet meer, hoe verder?
+We willen een analyse van ons applicatie landschap en advies over: hoe verder.
+We willen volgens IDesign werken maar hebben hulp nodig.
+We hebben een architect maar die heeft mentorship gevraagd.
+We zijn een startup en willen iets… (letterlijk “iets” 😉)
+We zijn een groot bedrijf maar onze dev capaciteit is volzet en we hebben een project wat zeker klaar moet zijn. Kan ilionx dit bouwen?
+We willen een IT partner die voor ons software kan bouwen waarbij kosten en tijdslijnen op voorhand meegedeeld kunnen worden en waarbij deze aspecten continu gemonitord worden.
+We hebben een 3rd party leverancier maar willen iemand onafhankelijk het werk laten beoordelen.
+Fulltime bij de klant als architect
+Fulltime intern projecten oppakken
+Architectuur consultancy: gedurende het project wekelijks 1 of meerdere malen onsite.
+Korte fulltime engagement om het project op te starten, wekelijks check achteraf op voortgang.
+The purpose of the Commercial phase of a project is to allow the project team to determine the initial goals, scope and structure of the project.
+| Tasks | +Req’d | +Role Responsible | +
|---|---|---|
| + | Yes |
+Project Management |
+
| + | Yes |
+Project Management |
+
+ Security Analysis + |
+Yes |
+Development |
+
+
+Preliminary Schedule Development +
+
|
+Yes |
+Project Management |
+
+ User Department Observation + |
+- |
+Product Management |
+
+ Measurements Development + |
+- |
+Project Management |
+
| Artifacts | +Req’d | +Role Responsible | +
|---|---|---|
Project Plan |
+Yes |
+Project Management |
+
Have you identified team members for each role of the team?
+Does the team include appropriate customer representation, with the needed authority to make decisions about features, priorities, and resources?
+Does the team have adequate Information Services representation that can ensure a smooth implementation, * training, and ongoing maintenance of the product?
+Have you identified the major features that will be included on this project?
+Have you identified the major risks associated with this project, along with mitigation strategies for those risks?
+Have you developed a high-level schedule for all phases of the project?
+Do the developers on the project have an adequate understanding of the business domain?
+Does the team have an understanding of the sensitivity of the data that will be handled through the system?
+Does the team know what measurements you are going to track throughout the project?
+The team formation process is modeled after the Microsoft Solutions Framework (MSF) Team Model. +This model identifies 6 roles for each project.
+The goal of this task is to identify at least one person to be the lead on each role. +Individuals may fulfill duties on more than one role. +Also, there may be more than one person fulfilling one role.
+For reference, a short description of each role is listed below.
+Product Management
+Satisfied Customers:
+This role is primarily responsible for giving requirements to the developers, prioritizing requirements within the project, and establishing the business case.
Program (Project) Management
+Delivery Within Project Constraints:
+This role is primarily responsible for making sure the project meets the established goals of the team, making sure it is delivered on time and within budget, allocation resources, facilitating communication, and driving critical decisions.
Development
+Delivery to Product Specifications:
+This role is primarily responsible for building the product such that it meets the needs of the customer, being a technological consultant, and creating and maintaining estimates.
Testing
+Release After Addressing All Issues:
+This role is primarily responsible for making sure all issues are known and addressed before release.
User Education
+Enhanced User Performance:
+This role is primarily responsible for making sure the users can be as productive as possible with the new (or revised) product, providing input on usability, and training the users on the product before and after release.
+For each project, a representative from DISC will fulfill this role.
Logistics Management
+Smooth Deployment and Ongoing Management:
+This role is primarily responsible for ensuring that the deployment goes as smoothly as possible and that the product is set up for long-term maintenance.
Risk Assessment is the process of perceiving, analyzing and preparing for (or dealing with) conditions or events which threaten the success of a project. +The amount of effort needed to assess risk is usually proportional to the size and scope of the project. +Since life changes as a project moves along, risk assessment must be done in all phases of the project.
+During the envisioning phase of a project, most of the risk assessment effort will be directed towards predicting which conditions or events which are the most likely to threaten the success of the project. +As such, your goals in risk assessment are:
+list as many potential dangers that can be reasonably foreseen
+determine the probability of occurrence for each danger listed
+determine the extent of potential loss for each danger listed
+Once this is done, re-order the entire list from most dangerous to least dangerous. +This will help keep things in perspective as the project wears on. +(Remember to re-order the list again when re-assessing the dangers in later phases.)
+Are the stakeholders actively involved in their role in the project?
+Are new features requested after the requirements have been declared complete?
+Do any features or products utilized violate the provided Information Security Guidelines?
+Do the requirements affect a change in other products not previously included in this project?
+Does inadequate testing contribute to a larger number of defects in the deployed product?
+The Project Plan combines the three main documents that must be completed for the Envisioning Phase. +These documents are: The Vision Document, the Project Structure Document, and the Master Risk Assessment Document. +The following is a description of the components of The Project Plan. +The official version of this document should be signed by the project team and stakeholders. +The signed copy of the document should be provided to the IS Administration Office for filing.
+Vision - Documents the description of the project’s deliverable as the solution to the stated need.
+Need - Why is this project needed? What is the problem definition?
+Goals and Objectives - What are the broad goals and objectives for the project?
+Feasibility - Has this project been determined as feasible for the University to complete?
+Constraints/Assumptions - What are the project assumptions and constraints?
+Scope Statement - What are the boundaries for the project? What is in and what is out?
+Schedule/Timeframe - What is the high level estimate for the timeframe of the project?
+Broad Design Considerations
+Measurable Goals - What are the team’s measures of success for the project?
+Team Organization - Who is the project team and what are their roles? See Team Formation for a description of the team roles.
+Staffing Management Plan - Documents the required human resources and their approximate contribution time for the project.
+Stakeholders - Who are the stakeholders?
+Email List - Documents the memebers of the project team and the email distribution list that was created for the project.
+Meeting Schedule - Documents when the team will meet and who is required to attend the meetings.
+Reporting Plan - Documents the various reports and items that must be communicated to keep the team and stakeholders thoroughly informed of the status of the project.
+How will change requests be handled?
+How will changes be tracked?
+Quality Assurance Plan (optional) - The process to evaluate the project’s performance to ensure that the project will perform within quality standards.
+The purpose of the Commercial phase of a project is to allow the project team to determine the initial goals, scope and structure of the project.
+| Tasks | +Req’d | +Role Responsible | +
|---|---|---|
| + | Yes |
+Project Management |
+
| + | Yes |
+Project Management |
+
+ Security Analysis + |
+Yes |
+Development |
+
+
+Preliminary Schedule Development +
+
|
+Yes |
+Project Management |
+
+ User Department Observation + |
+- |
+Product Management |
+
+ Measurements Development + |
+- |
+Project Management |
+
| Artifacts | +Req’d | +Role Responsible | +
|---|---|---|
| + | Yes |
+Project Management |
+
Have you identified team members for each role of the team?
+Does the team include appropriate customer representation, with the needed authority to make decisions about features, priorities, and resources?
+Does the team have adequate Information Services representation that can ensure a smooth implementation, * training, and ongoing maintenance of the product?
+Have you identified the major features that will be included on this project?
+Have you identified the major risks associated with this project, along with mitigation strategies for those risks?
+Have you developed a high-level schedule for all phases of the project?
+Do the developers on the project have an adequate understanding of the business domain?
+Does the team have an understanding of the sensitivity of the data that will be handled through the system?
+Does the team know what measurements you are going to track throughout the project?
+The team formation process is modeled after the Microsoft Solutions Framework (MSF) Team Model. +This model identifies 6 roles for each project.
+The goal of this task is to identify at least one person to be the lead on each role. +Individuals may fulfill duties on more than one role. +Also, there may be more than one person fulfilling one role.
+For reference, a short description of each role is listed below.
+Product Management
+Satisfied Customers:
+This role is primarily responsible for giving requirements to the developers, prioritizing requirements within the project, and establishing the business case.
Program (Project) Management
+Delivery Within Project Constraints:
+This role is primarily responsible for making sure the project meets the established goals of the team, making sure it is delivered on time and within budget, allocation resources, facilitating communication, and driving critical decisions.
Development
+Delivery to Product Specifications:
+This role is primarily responsible for building the product such that it meets the needs of the customer, being a technological consultant, and creating and maintaining estimates.
Testing
+Release After Addressing All Issues:
+This role is primarily responsible for making sure all issues are known and addressed before release.
User Education
+Enhanced User Performance:
+This role is primarily responsible for making sure the users can be as productive as possible with the new (or revised) product, providing input on usability, and training the users on the product before and after release.
+For each project, a representative from DISC will fulfill this role.
Logistics Management
+Smooth Deployment and Ongoing Management:
+This role is primarily responsible for ensuring that the deployment goes as smoothly as possible and that the product is set up for long-term maintenance.
Risk Assessment is the process of perceiving, analyzing and preparing for (or dealing with) conditions or events which threaten the success of a project. +The amount of effort needed to assess risk is usually proportional to the size and scope of the project. +Since life changes as a project moves along, risk assessment must be done in all phases of the project.
+During the envisioning phase of a project, most of the risk assessment effort will be directed towards predicting which conditions or events which are the most likely to threaten the success of the project. +As such, your goals in risk assessment are:
+list as many potential dangers that can be reasonably foreseen
+determine the probability of occurrence for each danger listed
+determine the extent of potential loss for each danger listed
+Once this is done, re-order the entire list from most dangerous to least dangerous. +This will help keep things in perspective as the project wears on. +(Remember to re-order the list again when re-assessing the dangers in later phases.)
+Are the stakeholders actively involved in their role in the project?
+Are new features requested after the requirements have been declared complete?
+Do any features or products utilized violate the provided Information Security Guidelines?
+Do the requirements affect a change in other products not previously included in this project?
+Does inadequate testing contribute to a larger number of defects in the deployed product?
+The purpose of the Commercial phase of a project is to allow the project team to determine the initial goals, scope and structure of the project.
+| Tasks | +Req’d | +Role Responsible | +
|---|---|---|
| + | Yes |
+Project Management |
+
| + | Yes |
+Project Management |
+
+ Security Analysis + |
+Yes |
+Development |
+
+
+Preliminary Schedule Development +
+
|
+Yes |
+Project Management |
+
+ User Department Observation + |
+- |
+Product Management |
+
+ Measurements Development + |
+- |
+Project Management |
+
| Artifacts | +Req’d | +Role Responsible | +
|---|---|---|
Project Plan |
+Yes |
+Project Management |
+
Have you identified team members for each role of the team?
+Does the team include appropriate customer representation, with the needed authority to make decisions about features, priorities, and resources?
+Does the team have adequate Information Services representation that can ensure a smooth implementation, * training, and ongoing maintenance of the product?
+Have you identified the major features that will be included on this project?
+Have you identified the major risks associated with this project, along with mitigation strategies for those risks?
+Have you developed a high-level schedule for all phases of the project?
+Do the developers on the project have an adequate understanding of the business domain?
+Does the team have an understanding of the sensitivity of the data that will be handled through the system?
+Does the team know what measurements you are going to track throughout the project?
+Project Scope and Vision Approved
+The Commercial phase is complete when the entire team and stakeholders have come to an agreement regarding the scope and structure of the project.
+The team formation process is modeled after the Microsoft Solutions Framework (MSF) Team Model. +This model identifies 6 roles for each project.
+The goal of this task is to identify at least one person to be the lead on each role. +Individuals may fulfill duties on more than one role. +Also, there may be more than one person fulfilling one role.
+For reference, a short description of each role is listed below.
+Product Management
+Satisfied Customers:
+This role is primarily responsible for giving requirements to the developers, prioritizing requirements within the project, and establishing the business case.
Program (Project) Management
+Delivery Within Project Constraints:
+This role is primarily responsible for making sure the project meets the established goals of the team, making sure it is delivered on time and within budget, allocation resources, facilitating communication, and driving critical decisions.
Development
+Delivery to Product Specifications:
+This role is primarily responsible for building the product such that it meets the needs of the customer, being a technological consultant, and creating and maintaining estimates.
Testing
+Release After Addressing All Issues:
+This role is primarily responsible for making sure all issues are known and addressed before release.
User Education
+Enhanced User Performance:
+This role is primarily responsible for making sure the users can be as productive as possible with the new (or revised) product, providing input on usability, and training the users on the product before and after release.
+For each project, a representative from DISC will fulfill this role.
Logistics Management
+Smooth Deployment and Ongoing Management:
+This role is primarily responsible for ensuring that the deployment goes as smoothly as possible and that the product is set up for long-term maintenance.
Risk Assessment is the process of perceiving, analyzing and preparing for (or dealing with) conditions or events which threaten the success of a project. +The amount of effort needed to assess risk is usually proportional to the size and scope of the project. +Since life changes as a project moves along, risk assessment must be done in all phases of the project.
+During the envisioning phase of a project, most of the risk assessment effort will be directed towards predicting which conditions or events which are the most likely to threaten the success of the project. +As such, your goals in risk assessment are:
+list as many potential dangers that can be reasonably foreseen
+determine the probability of occurrence for each danger listed
+determine the extent of potential loss for each danger listed
+Once this is done, re-order the entire list from most dangerous to least dangerous. +This will help keep things in perspective as the project wears on. +(Remember to re-order the list again when re-assessing the dangers in later phases.)
+Are the stakeholders actively involved in their role in the project?
+Are new features requested after the requirements have been declared complete?
+Do any features or products utilized violate the provided Information Security Guidelines?
+Do the requirements affect a change in other products not previously included in this project?
+Does inadequate testing contribute to a larger number of defects in the deployed product?
+The page you requested has been relocated to https://xadm.ilionx.com/component-xadm/0.1.0/introduction.html.
diff --git a/sitemap.xml b/sitemap.xml new file mode 100644 index 0000000..712c3d1 --- /dev/null +++ b/sitemap.xml @@ -0,0 +1,35 @@ + +