Internals of the Panduring Process Model
Episode -03 of “The genesis of a Process Model”
The following blog will discuss the process flow and the phases of the proposed “Panduring Process Model”. It might be required to have a brief introduction to Panduring process model and the necessity to propose such a process model during this pandemic.
Episode 01:Pandemic has exposed the vulnerabilities of _* ?
Episode 02: The Panduring Process Model
Phases and Processes
The model is basically into three important phases
1. Design Phase
2. Implementation Phase
3. Integration Phase
There are basically 6 processes that would span across the phases.
1. Requirement Engineering
6. Deployment & Support
Explaining the flow of processes
● Initially the project begins with the buffer time. This time is utilized to prepare and arrange to fall into the model after the model switch. Whatever the state you are in of your previous model buffer time will stress on preparing relevant SRS(Software Requirement Specification) , SDS (Software Design Specification), methodology documents (MD). These documents never need to be comprehensive but should provide an overall idea and since iterative can integrate more details later on. The Panduring model requires following the step structure it prescribes. After a certain time of requirement study, can proceed into the research process (not before 2 weeks into Requirement Engineering).
● Research process involves several existing architectures, systems, best practices and proposes some approaches for the system. There will be iterations of discussions with requirement engineers to shape the research process. The trade-off, priorities, feasibility will be discussed.
● While being in the research phase for weeks, can begin the initial design with the overall idea (even without a methodology document but with a released SRS & not before 5 weeks from project initiation). Then the official methodology document will be released and can then finalize the design and produce SDS.
● Only after the release of SDS, the implementation process will begin. There will be no iteration here from design to implementation and implementers will be working on fixed SRS. But this will not prevent the customers in adding new features or modifying requirement. Requirement engineering, research and design process will continue to iterate, and the changes will be added into ‘Requirement’, ‘Design’ backlog. The implementation continues to produce a POC(Proof-of-concept) prototype.
● Once after the release of the POC prototype which marks the exit from design phase, the process begins from requirements engineering again to mark the beginning of Implementation phase. Now the ‘requirement backlog’ is considered (or cleared) and revised and added into SRS. Similarly if there are any changes needed, the research process will pass it to the design phase. Now design process clears the ‘design backlog’ and review to know if there are any other changes and add them to SDS. Then implementation for the actual system begins with revised SRS and SDS. Now the design process and implementation process become separate and any new changes are added to relevant backlogs.
● In this implementation phase it will iteratively progress with testing to produce an executable system and with the demonstration the process shifts to requirement engineering to establish the phase shift from implementation phase to integration phase. Follow the similar approach of backlog clearing and updating SRS, SDS.
● After the complete flow, testing report, user and developer manual will be released, and product/system will be shipped and deployed (deployment & support process) and continue to provide support.
● Support (part of deployment and support) is a similar step structure from requirement engineering to deploy.
This phase focuses on two different aspects of the project. First one is regarding the project’s launch. For the budget to get approved, it is necessary to validate the project. Project plan, project description which includes core requirements, constraints, cost estimates and key features, initial risk assessment and are produced. Actors and the nature of their interaction are defined. During this phase, project stakeholders are expected to give full commitment. Dedicated engineers will facilitate the phase.
After the initial assessment of project feasibility, the team will continuously interact to refine more on requirements, validate the priorities, discuss the risk and cost and duration, and elicit and define SRS. Requirements should be thoroughly understood. Initial technical and resource limitations should be analyzed and decided as how to proceed. Cost and schedule estimates should be credible. It is not necessitated to have a complete study of costs and timeline, but it is necessitated that a rough idea to be discussed and agreed upon. An SRS document (a document with the well refined project’s functional, non-function and domain requirements, key features, and main constraints) should be prepared. This is the first milestone/deliverable in the project.
Secondly, this phase focuses on addressing the project’s major technical risks. The purpose of this phase is to do research about the requirements and how we can approach to provide solutions, set of methodologies to cater the demands and create the architecture of the system. That is this is where the project starts to take shape. At the end of this phase, the team should be in a position to decide whether they can develop a working system.
The phase involved in preparing methodology documents and Software design documents which elaborates on a chosen methodology prescribed in the methodology document. This phase is the most critical one among other phases as a major decision is taken during this phase to evaluate whether the requirements are reliable technically and the set of approaches towards the end systems and an elaborated structural design on a chosen methodology (whether to commit to the project or not). There will be several iterations of discussions between design, research and requirements engineering processes. Until SDS is released all changes to SRS and methodologies will be integrated. Then with SDS the design implementation begins to produce a POC prototype which marks the exit of the phase. During this design implementation, all the requirement or design changes will be added to relevant backlogs and not into SRS, SDS.
This phase focuses mainly on producing a functioning system by using the architecture that was designed during the previous phase. Developing components and other features and extensive testing are done during this phase. In large projects, there can be many implementation phases. Therefore this is helpful as it is possible to divide use cases into smaller and manageable segments.
Phase acquires requirement or design changes from backlogs, refine them and add them to SRS, SDS and continue sheer implementation and testing to produce the fully functional executable systems. The major milestones are fully functional system, and Test report. There is no direct forward of changes from design, requirement engineering to the implementers once implementation begins. Once implementation begins requirement changes are accepted, discussed, and updated in requirement backlog. Same as based on requirement changes and other nonfunctional and functional changes the changes in design also tracked on to the design backlog. Delivery of Executable system and its demonstration marks the end of the phase.
This phase focuses on deploying the systems after a small but a complete interaction of requirements to testing. The completed systems will be deployed into the customer’s environment. In this stage, the system is evaluated and refined based on the feedback of users in order to fulfill the requirements and needs of users. This is done only to polish the system since it already meets the users’ requirements. Training end users are also included in this phase. The product is checked against the quality standards that were set in the inception phase. At the end of this phase, the system is released and the project is evaluated. This phase has n exit as it would continue to provide user support at least for a short while[ or as per plan] and user manual and developer manual are important deliverables or milestones that helps the system users to get adapted and developer manual extends the support for support engineers when there will be future increments. The support will refresh with the requirement study and then proceed along the steps to reach the implementation testing and deployment
Each phase in this model will include some or all of the development workflows. But what differs is the amount of work in each workflow. For example, work in the initiation phase focuses mostly on business modeling and gathering requirements whereas in the implementation phase, whole focus will be on implementation.
The process model insists on a strict support for documentation. This is to ensure the maintainability of code and anytime drift from a process model to another process model.
1. Software Requirement Specification (SRS)
A Software requirements specification document describes the intended purpose, requirements and nature of software to be developed. The document includes the functional, nonfunctional and the domain requirements. And modeled through UML.
2. Methodologies Document (MD)
Describes several approaches to be taken to investigate the requirements of the project and the rationale for the application of specific procedures or techniques used to identify, select, process, and analyze information applied to understanding the problem. The document includes several approaches towards the design and implementation of expected systems and requirements. This document is more prolific in projects that require more research [Machine learning]. This will have several ways of approaching the design of the architecture.
3. Software Design Specification (SDS)
This documentation provides details of how the software system should be built. SDS includes use case models, collaboration models, sequence diagrams, objects behavior models etc. The purpose of this document is to provide a description of the design of a system which is sufficient to allow for the development process to proceed.
4. POC Prototype (Proof-of-concept Prototype)
The main purpose of developing a POC is to demonstrate the functionality and to verify a certain concept or theory that can be achieved in development. Prototyping allows the developers to visualize how the product will function. While a POC shows the customer stakeholder that a product or feature can be developed that realizes the design and the methodology, a prototype shows the implementers that How it will be developed and the crux of the system.
5. Executable systems
This will be the fully functional executable systems that will be shipped for customers to evaluate the model; how the system is performing; have the system fulfilled the prescribed requirements; is all the system doing well. It is a kind of alpha and beta testing of the system
6. Testing report
Document that records data obtained from an evaluation experiment in an organized manner, describes the environmental or operating conditions, and shows the comparison of test results with test objectives.
7. User manual
Document, which is intended to give assistance to the stakeholders, users of a particular system
8. Developer manual
The collection of documents that describes the requirements, capabilities, limitations, design, operation, and maintenance of a system, such as a communications, computing, or information processing system
The process model is prescribed for projects that span a period of three-six months period. But if the project is too long, can split the project into several smaller phases and then operate in multiple phases.
For an example, if the project duration is 3 years or consider a project which is bigger. One way is to increase the number of engineers and technicians. But if it not feasible with limited resources and if time can be extended for a considerable terms, it is advisory to divide the project into 6 phases with a phase having a 6 month durability. Here the documentations will help the flow and since there will be POC prototype and demonstration , it is recommend to develop subsystem wise .Then the adversity of the waterfall model is addresses here as customers can see how the project is shaping up and their considerations will be always logged to backlogs and then brought to development.
Here is a sample of a bigger project. If it is to be done with one team then it requires 3 years. Else you need to bring three more teams. So with workers limitations, can borrow some time, can do it in 6 phases.
Thanks for reading the blog up to this point. Appreciate your comments on the proposed model.Your feedback will eventually shape the process model and might end up being used by anyone of the software institution. The blogs on Panduring process model has to be broken down into a series because of the length and my strong belief is that you folks will wait till the next episode (Episode 04) to know more about proposed team architecture and the main events in relation to Panduring model.