How can agile software development fit into SETR events?
Agile being iteritive in nature seems contrary to the "waterfall" event based SETR Life Cycle. For example when does SRR, PDR, or CDR take place? How many times should each review occur? Since agile breaks tasks into small increments with minimal planning and does not involve long-term planning it becomes difficult to convince a TRB that we are on the right path.
“Agile software development” is a blanket term used to describe various software development methodologies which implement some of the Values and Principles defined in the Agile Manifesto (http://agilemanifesto.org/). There are various agile software development methodologies (eXtreme Programming (XP), SCRUM, etc...) which you can use. Each methodology has its strengths and weaknesses and each one is better suited for different development environments. It sounds like you are speaking about Rapid Application Development (RAD). In general, this agile development methodology uses rapid prototypes and less planning. However, there are other methodologies that may be a better fit for the situation you described.
Open full Question Details
You may consider looking at Scrum, which is an agile project management methodology that takes a capability (something of value to the user) and breaks the capability down into small increments (Sprints). At the end of each Sprint the final product is shown to the user to ensure it meets the user’s expectations. This product is generally not just prototype but is a “potentially shippable piece of code.” An important characteristic of each Sprint is explicitly defining a “definition of done” for each Sprint. The “definition of done” specifies exactly what each increment will produce which may include things like: testing, documentation, Information Assurance requirements, etc.. No credit is given unless all of the items in the “definition of done” are complete, so you should never be stuck with a software item that is “95%” complete. I have also seen Scrum expanded to the System Level which addresses long term planning for larger systems engineering efforts. This appears to be best suited for your environment.
Though initially the incremental / iterative nature of agile development seems contradictory to the traditional “waterfall" methodology you can use agile development practices to manage the project. Even though you may have one delivery at the end of the “waterfall”, under the covers you can break up the final delivery into smaller pieces (increments and iterations) to allow for better project tracking and risk reduction. So your decomposed agile project plan would include the required reviews (SRR, PDR, etc.) which would take place according to the status of the project (event based) – though keep in mind you will initially have a target date for the reviews. You could roll the requirements for each review into the Sprints to track the progress leading up to the review in order to ensure you are on track to meet the review date.
There is no predetermined number of times each review occurs as this will vary from project to project. One approach is to have smaller (informal) PDR’s or CDR’s at the end of some Sprints so when a larger review (if still required) is conducted, it is simply a review of items that have already been seen / approved.
If proper system engineering best practices and an agile development methodology such as Scrum (adding the system level planning) is used, your Technology Review Board should have a high level of confidence that you are “on the right path” since you have long term plan and you are able to track each item at the sprint level to better assess the overall project progress.