Skip to main content Accessibility help
×
  1. Home
  2. Browse subjects
  3. Engineering
  4. Electronic, optoelectronic devices, and nanotechnology
  5. Content listing

Refine search

Refine search

Access:
Content type:
Publication date:
Apply   From and To filters
Subject: Show more
Journals Show more
Publishers: Show more
Societies Show more
Series: Show more
Collections: Show more

Actions for selected content:

Select all | Deselect all
  • View selected items
  • Export citations
  • Download PDF (zip)
  • Save to Kindle
  • Save to Dropbox
  • Save to Google Drive

Save Search

You can save your searches here and later view and run them again in "My saved searches".

Please provide a title, maximum of 40 characters.
Cancel
×

5077 results in Electronic, optoelectronic devices, and nanotechnology

Page 69 of 254

  • 8 - Extended KDD: Pre-Requirement and Post Delivery

  • Manoj Kumar Lal
  • Book:
    Knowledge Driven Development
    Published online:
    20 October 2018
    Print publication:
    08 March 2018, pp 169-171

  • Summary

    In this chapter, we look at the product lifecycle rather than project lifecycle. Before a project starts via defined requirements, a business case must be established. Also, once the product is delivered, it is supported by the service management for support and maintenance until it is decommissioned. These two phases of the product delivery should also get the benefit from the concept of digital Project Knowledge Model. This chapter discusses the relevance of PKM in these two phases of the product delivery that can be covered by the Extended KDD.

    Business Case (Pre-Requirement)

    Cost of delivering software must be significantly less than the benefit it can deliver within a specified period, as determined by the customer. This makes the business case for the delivery of a software. A software delivery project usually passes through the business case before the requirement analysis phase of the project can start. Monetary considerations are always the key, either directly or indirectly. Indirect monetary considerations are obvious in regulatory and technology upgrade projects. Non-compliance with regulatory requirements might incur a heavy penalty, and technology upgrades, if not done, can result in unpredictable interruptions of services.

    There are usually two identifiable phases in the product delivery before the requirement analysis phase begins. They are:

  • 1. Initiation phase where an idea is generated and assessed for feasibility and cost-benefit. It goes through the scrutiny of the senior management to ensure it is as per the goals of the company and fit to go to the next phase.

  • 2. Concept phase, where As Is and To Be are detailed and, if needed, multiple solution options are arrived at. Out of them, one solution option is chosen, to be detailed further. There will always be a default option of not to do anything. For choosing a solution option, cost-benefit considerations are the key. Once a solution option is chosen, high level requirements are created, which become the input to the requirement analysis phase, which is the first phase of project delivery as detailed in the earlier chapters.

    • One of the biggest challenges in these early phases of product delivery is determining the size of the work. This is where the enterprise knowledge base of PKM comes to help. For each of these initial phases of initiation and concept, enterprise knowledge base can be used to size the work.

  • Appendix E - KDD: Response to Criticism

  • Manoj Kumar Lal
  • Book:
    Knowledge Driven Development
    Published online:
    20 October 2018
    Print publication:
    08 March 2018, pp 281-285

  • Summary

    Although KDD is not in the open forum for discussion about its merits and demerits (this book is the first attempt to take it to the industry and academia), while evolving this methodology and writing the book, it was exposed to many academicians and practitioners of software engineering. A list of concerns expressed by the experts and my responses to these concerns are given here.

    Criticism 1

    Computers cannot generate a fully readable document set representing complete project knowledge. Knowledge can never be fully defined (and will always be subjective) in a way that can be automated by a computer.

    Response

    Documents referred are related to project knowledge such as BRS, FSD, HLD and Test Cases. People who are sufficiently skilled in producing these documents have enough knowledge about them. But everyone has an individual style, whether it is writing, presenting or explaining. The personal experience of the author influences the document produced. Different people can present the same information differently. Some would write crisp and clear descriptions and some would write details covering detailed background information as well.

    This suggests that, because computers cannot think, they cannot produce a project document as the project documents need creative thinking. Computers can only process information based on algorithms and it is assumed that it is difficult to write an algorithm to capture knowledge.

    However, KDD has done something noteworthy. It has created a framework which defines and scopes the entire project knowledge. It expects the project team to capture the project knowledge using the same framework. It minimises the variations that are caused in a typical documentation regime. PKM provides a mechanism to capture the project knowledge in such a format which allows a computer to extract it in a document format.

    Let us appreciate the robustness of PKM. Any information related to the project can be captured completely via the combination of inventory and relationship. There are only two activities involved here. The first one is defining the inventory of a building block via a set of mandatory and optional attributes. The second one is linking all the inventories together. When all the inventories are traced, it clearly brings out their many-to-many relationships, completing the nested knowledge. This brings the rigour and maturity to the model which makes it easier for a computer to extract a document based on an algorithm.

  • 11 - Addressing Contemporary Concerns of Project Delivery

  • Manoj Kumar Lal
  • Book:
    Knowledge Driven Development
    Published online:
    20 October 2018
    Print publication:
    08 March 2018, pp 203-213

  • Summary

    As discussed in the earlier chapters, smooth project delivery is still a challenge and the IT industry is continuously working to make the project delivery more effective. This chapter discusses the relevance of KDD to important topics that are of interest for effective project delivery, other than DevOps and automation. The relevance of KDD to DevOps and automation has been discussed in separate chapters.

    Shift Left

    Shift Left refers to a practice in software development where teams focus on quality, work on prevention instead of detection and begin testing earlier than ever before. The goal is to increase quality, shorten long test cycles and reduce the possibility of unpleasant surprises towards the end of the development lifecycle.

    Following traditional methodologies results in a substantial testing phase of the project delivery, and significant effort is spent on rework due to oversights made in the pre-testing phases. KDD, via its negative relationships and manual review of the catalogued project knowledge elements (requirement, solution design, application design and test design) that are integrated via exhaustive traceability, creates an effective static testing environment that has been largely absent in the existing methodologies.

    The cost of quality in a typical project is close to 50% (in my experience) with the break-up as follows:

  • 1. About 25% effort goes in in test design, execution and management.

  • 2. One-third of the remaining 75% effort typically goes towards review and rework.

    • Shift left aims to optimise this one third of the remaining effort so that the test execution can be almost defect free. KDD reduces this one third of the review and rework effort through the catalogued knowledge capturing mechanism, the negative relationships review and manual review. Its benefits are:

  • 1. Review and rework is digitised via 516 data points of project knowledge and the related quality assurance. Due to the scientific way of handling review and rework, KDD reduces this effort up to 50% of the existing effort.

  • 2. Test cases are prepared by reusing inventories of solution design. OATS technique is used for optimised coverage. The entire set of test cases (from unit test to UAT) is prepared at one go and in the same format. Considering traditional end-to-end test design by different teams, the KDD approach has the potential to reduce the efforts spent in test design by half.

  • Preface

  • Manoj Kumar Lal
  • Book:
    Knowledge Driven Development
    Published online:
    20 October 2018
    Print publication:
    08 March 2018, pp xix-xxii

  • Summary

    Let's visualise IT project delivery as consisting of two segments. The first, dealing with requirement gathering and analysis, and detailing the solution from the business and technical perspective. The second, dealing with coding, testing and implementing the software. The first represents project knowledge and the second relates to its technical implementation. Software engineering focuses on both. While there has been a significant advancement in technical implementation, project knowledge has not matured at the same rate. Project knowledge is still plagued with gaps in effective representation, communication, competency and quality assurance, and there is significant opportunity to improve this area.

    We try to manage project knowledge largely through experienced associates, strong adherence to processes and documentation, and robust communication with stakeholders. In this book, I have gone deeper into this by decomposing knowledge and representing it via data points. I have conceptualised the Project Knowledge Model (PKM) to manage the project knowledge in a structured manner. PKM catalogues the entire project knowledge and integrates it together with an exhaustive traceability mechanism. PKM has the potential to assist all the existing project delivery methodologies. It digitises project knowledge which, in turn, assists in the technical implementation of the software as well.

    I have expanded PKM to cover end-to-end project delivery and evolved a new methodology of project delivery, named Knowledge Driven Development (KDD). KDD is driven by PKM and blends the Waterfall and Agile project delivery concepts. The bridging of the gap between Waterfall and Agile project delivery is an underlying theme that runs throughout this book and is a positive spin-off from the digitisation of project knowledge.

    Taking the knowledge decomposition concept beyond IT, I have also evolved a Generic Knowledge Management Framework (GKMF) which has the potential to manage generic knowledge and assist in skill development.

    This book introduces PKM, KDD and GKMF with a case study and examples. It elaborates PKM and explains how the model may help the project delivery, regardless of the project delivery methodology followed. The idea is still conceptual and untested but matured enough to be presentable. Objective of this book is to present the idea in a meaningful manner to enable further work on it.

    What inspired me the most to work towards this methodology were the numerous instances of lost time, misdirected effort and the ensuing delays in project delivery.

  • 13 - Technology Enablers: Tools and Automation

  • Manoj Kumar Lal
  • Book:
    Knowledge Driven Development
    Published online:
    20 October 2018
    Print publication:
    08 March 2018, pp 220-232

  • Summary

    Tools can assist to implement a project delivery methodology. PKM provides an opportunity to bring in sensible automation of the project delivery. I believe that a tool can be created to implement PKM, customised to the environment suitable to the organisation needs. The tool may be based on project knowledge and its quality assurance. It may be enhanced by adding other standard features such as collaboration, configuration management and work flow. It may also be expanded to support the execution and management related activities. It may then be used to automate most of the project delivery.

    This chapter identifies category of tools existing in the market for project delivery. It visualises how PKM can enhance existing tools. It also visualises PKM as a tool at a conceptual level.

    Automation Potential in Project Delivery

    Let us try to understand the automation potential of project delivery from the perspective of KDD. Project delivery consists of activities related to project knowledge and project execution, as well as management of both.

    There are tools around project knowledge that are either requirement driven or test driven, but they are generally weak in solution design and application design. There are tools specialised in certain areas of solution design or application design, such as business process modelling tools.

    In project execution, there are packages which have reduced the role of coding and rely more on customising the product. SAP is a representative example. In cases where there are no packages, the latest programming languages have made coding easier assisting the development team.

    Automation of build (code generation) from detailed specifications is also possible.

    Project management tools are also available in the market. They are used for planning, estimating and monitoring purposes, where the data from the project knowledge and execution phases is fed manually most of the time.

    Considering project delivery from the knowledge perspective can bring more maturity to the automation efforts. Let us understand it in details as below.

    End-to-end project delivery creates five forms of project knowledge:

  • a. Requirement and high-level scoping information

  • b. Solution design

  • c. Application design

  • d. Test design

  • e. Developed Application (Code)

    • Each of these forms of project knowledge is complete in itself and can be mapped to others at the lowest level. One interesting deviation is requirement.

  • 17 - Conclusion

  • Manoj Kumar Lal
  • Book:
    Knowledge Driven Development
    Published online:
    20 October 2018
    Print publication:
    08 March 2018, pp 261-264

  • Summary

    Mind, which is the warehouse of knowledge, is ever elusive. On one hand, it is so powerful that, according to Indian spiritual belief, it can visualise objects thousands of miles away in no time, and on the other hand, it is so weak that it may not even recollect what was said a minute earlier. This can be the situation of the same mind at different times. Variation in the way the mind works is dependent on the person's nature and upbringing. When many people (minds) get together to work in an IT project which is knowledge intensive, chaos is expected, by default. Even if a small portion of these minds can be synchronised to work together, project delivery can be significantly improved. KDD is an attempt to assist in synchronisation of the minds by giving a tangible structure to the intangible knowledge. It encourages people (minds) to work together on knowledge intensive areas. Through this book, an attempt is made to provide a mechanism to structure knowledge, both in IT industry (via PKM) and in general (via GKMF).

    PKM

    PKM, with its 18 building blocks, helps digitising project knowledge. This leads to the evolution of KDD methodology to manage end-to-end project delivery. KDD emphasises on enterprise knowledge reuse as much as possible, which differentiates it from other methodologies. The initial phases in KDD are more like Waterfall, where a certainty of requirement and solution is required. The later phases in KDD are more like Agile, where the bulk of the work is accomplished in a parallel and iterative manner, splitting the work into logical units.

    Let us look at the knowledge gap in different methodologies. Figure 17.1 indicates the knowledge gap in the lifecycle of the product, from software development to its decommissioning. In Waterfall, the knowledge gap is widened, particularly at the point of handover and takeover between different teams since the mechanism for recording and storing knowledge is documents, which are costly to be reviewed and difficult to be kept updated. In Agile, the knowledge gap is relatively smaller in the software development phase, remains the same in the business area and increases in the service delivery area as there is a lack of reliable and exhaustive project knowledge to be handed over.

  • 5 - Project Knowledge Model: A Differentiator

  • Manoj Kumar Lal
  • Book:
    Knowledge Driven Development
    Published online:
    20 October 2018
    Print publication:
    08 March 2018, pp 97-120

  • Summary

    Having introduced PKM in chapter 4, this chapter presents its uniqueness in the project delivery environment.

    Digitisation of the project knowledge is the core proposition of PKM. This chapter continues to identify and detail the differentiators provided by PKM that accelerate the project delivery with enhanced quality. This chapter identifies the reasons why this model could not be visualised much earlier. Finally, it summarises the benefits that project delivery would accrue from the model.

    Project Knowledge Model Characteristics: Traceability and Flexibility

    Digitising project knowledge via traceability and in-built flexibility are the main characteristic of PKM.

    The completeness of the project knowledge is ensured by:

  • 1. Building block inventories (such as for requirement building bock, the inventory may be Requirement_01, Requirement_02) that can be completely specified by its mandatory and optional attributes (Requirement Id: mandatory field, Related department: optional field).

  • 2. Exhaustive traceability (171 to be precise, for a typical implementation) capturing links between the two inventories keep the knowledge digitised and integrated in a single repository. In a traditional project there may be up-to ten relationships of traceability. PKM provides the capability to manage up-to 171 relationships (for example) of traceability in the project helping specify the project knowledge completely.

    • There is a significant difference between relationship of the Project Knowledge Model and traceability used in traditional sense. In PKM, the inventory that is traced, represents the lowest logical unit of information. Its completeness is to the extent that when inventories are combined with linkages, it represents complete project knowledge. In traditional traceability, it is a challenge to represent inventories at the lowest and logically complete information, as they are unstructured sentences and paragraphs in sections of the documents, difficult to be traced unambiguously.

    In addition to being complete and fully traceable project knowledge, it is also flexible enough to cater for subjectivity as explained in the following:

  • 1. The number of building blocks is subjective and can vary based on the context and subjectivity of the SME.

  • 2. Attributes defining building blocks completely may be different for different organisations as they need to be evolved by the relevant SMEs.

  • 3. Many of the 171 relationships may not have much practical usage and hence can be de-scoped for greater speed of project delivery by the project SMEs. One example may be the relationship between the building blocks ‘Non-functional attributes’ and ‘Communication’.

  • 3 - Project Delivery Pain Areas and the Way Forward

  • Manoj Kumar Lal
  • Book:
    Knowledge Driven Development
    Published online:
    20 October 2018
    Print publication:
    08 March 2018, pp 46-58

  • Summary

    This chapter provides the context of the book and summarises how a new methodology of IT project delivery has evolved. It lists out some major failures of IT projects in the past, mentions the challenges in project delivery and identifies the root causes. It explains the reduced usage of the Waterfall project delivery methodology, having failed to keep project documents updated in real-time. It also explains the downgrading of the importance of project documentation in the Agile methodology. It introduces an alternate way of creating and maintaining project knowledge which is currently present in documents.

    Context

    Maturity in software project delivery is still low despite having numerous methodologies available to drive it. Methodologies generally fall under two families: Waterfall and Agile. The latest global data from the Standish Group [2], tracking over 50,000 projects during 2011–2015, shows that the success rate of Waterfall is 11% and Agile is 39%.

    The book has taken the scientific structure of Waterfall and the dynamic approach of Agile, combined it with PKM and evolved a new IT project delivery methodology, which I refer to as Knowledge Driven Development (KDD).

    An important reason for project failure is lack of availability of ‘fit-for-purpose’ information and timely communication across project stakeholders. In Waterfall methodology, the information and its communication are accomplished by project documents stored in a commonly accessible location. Documents change under version control with a sign-off mechanism, making it difficult to keep the document up-to-date in a continuously evolving project delivery environment. If a defect in the document is detected, say, today. It might take a month before the new version of the document is released addressing the defect (due to the sign-off mechanism). The other limiting factor is the document itself as it is written in free-form text and keeping it consistently updated involves significant effort. In Agile methodology, the situation is not better as the documents are not meant to be exhaustive enough to be considered as containing ‘fit-for-purpose’ information. The information is primarily communicated through face-to-face discussions, making it person dependent. Agile assumes fully skilled team members, and any attrition or absence might be a challenge. The only reliable source of information is code, which is written in technical language that only the technologists in the project can understand.

  • 7 - Extending Project Knowledge Model to Cover End-to-End Project Delivery – KDD

  • Manoj Kumar Lal
  • Book:
    Knowledge Driven Development
    Published online:
    20 October 2018
    Print publication:
    08 March 2018, pp 140-168

  • Summary

    This chapter shows how PKM drives project delivery. PKM is expanded to Extended PKM (EPKM) to include majority of execution and management related activities so that it can cover end-to-end project delivery. It gives rise to Knowledge Driven Development (KDD) – a new project delivery methodology.

    The chapter starts with understanding the broad scope of KDD in project delivery. Concepts important to appreciate KDD are detailed. The end-to-end project delivery phases are traversed using KDD via the standard quality gate approach. Other aspects of project delivery such as quality are also considered. Relevance of KDD across domain and types of projects are discussed. At the end, the chapter lists out differentiators that KDD is trying to bring in.

    Introduction

    As discussed in chapter 4, there are three types of activities in project delivery, i.e., relating to knowledge, execution and management. The project knowledge related activities are the most important and covered by PKM. PKM digitises the project knowledge to an extent that makes it possible to bring in similar digitisation in the activities related to execution and management. PKM can be extended to cover a majority of the execution and management related activities and a new project delivery method can be conceived. This has resulted in the evolution of Knowledge Driven Development or KDD.

    As discussed in chapter 2, there are three basic characteristics on which project delivery methodologies are based upon:

  • a. Structured or empirical

  • b. Sequential or iterative

  • c. Full delivery or delivery in increments

    • Waterfall is structured, sequential and typically full delivery in one go and Agile is empirical, iterative and incremental delivery. KDD can be categorised as:

  • a. Mix of structured (with its 189 data points of project knowledge) and empirical (evolved over the years based on experience, research and interaction with experts). The ideas may be intuitive but they are not proven yet and hence empirical.

  • b. Mix of sequential (solution design does not start before requirements are matured to a significant extent), non-sequential (test design and application design start in parallel after solution design) and iterative (once the project knowledge is specified completely, it becomes easy to create build and test execution into logical units, suitable for iteration).

  • b. c. It has the flexibility of full delivery and incremental delivery depending on need. Due to digital knowledge management, increments can be managed effectively.

  • 6 - Project Knowledge Model vs Project Documents

  • Manoj Kumar Lal
  • Book:
    Knowledge Driven Development
    Published online:
    20 October 2018
    Print publication:
    08 March 2018, pp 121-139

  • Summary

    Although this topic is touched upon in the previous chapters, this chapter concentrates on comparing PKM against project documents with respect to the creation and maintenance of project knowledge. It introduces both the mechanisms and provides an exhaustive comparison of the two from different perspectives. An example is provided for both document extract and PKM extract to aid understanding of their differences. It also details the artefact sets that can be extracted from PKM.

    Project Knowledge Model and Project Documents

    Figure 6.1 depicts how knowledge is managed in a typical project delivery from the perspectives of PKM and document production regime. Document production regime is based on Waterfall (structured) methodology. Agile methodology have a sleeker version of the document production regime.

    Any methodology of software development starts from gathering requirements and ends with the working software and the related specifications of the software. The traditional methodologies have been relying on document production regime for capturing specifications of the software from solution, technical and test perspective. In the Waterfall methodology, emphasis is given on rigorous maintenance of the documents during different phases of the project delivery. Agile methodology go for ‘fit-for-purpose’ documentation and documents are kept at high level so that they do not need frequent changes.

    As mentioned earlier, keeping the documents updated in real-time is a challenging task in project delivery and that causes a lot of gaps in communication, ultimately delaying the project. This is one reason the Agile methodology only go for high level documentation that does not need frequent updates.

    The main issue with the document production regime is that there is a need to update the contents of the documents regularly as the project progresses through different phases. But the problem is the before the updated document can be issued, it needs to be approved by the relevant stakeholders. The revised version of the documents is mostly issued on reaching selected milestones. For example, in Figure 6.1, six versions of BRS (Business Requirement Specification) are visualised over the course of the project delivery lifecycle. Let us say there is a gap of two months before the next version of the BRS is scheduled to be released. From the couple of days of release of the last version, the information contained in the document may not be the latest.

  • 15 - Global Relevance of KDD: GKMF Assisting Skill Development

  • Manoj Kumar Lal
  • Book:
    Knowledge Driven Development
    Published online:
    20 October 2018
    Print publication:
    08 March 2018, pp 241-256

  • Summary

    KDD, as an IT project delivery methodology, is still in its infancy and this book is the first attempt to bring the concept to the academia and industry. As it relates to knowledge, the concepts of KDD are also relevant to areas other than IT project delivery.

    In chapter 1, we have seen how knowledge is split into four levels that can be captured in eight building blocks. In chapter 4, we have seen how these eight building blocks, when customised to IT project delivery, become 18 building blocks. In this chapter we will reverse engineer 18 building blocks and understand how they comply with the Generic Knowledge Management Framework (GKMF) introduced in chapter 1. We will go through examples of KDD in action in areas other than software development.

    We will focus on the domain knowledge portion of GKMF. Through examples, we will demonstrate that GKMF has all the capability to grow into a skill development framework.

    KDD and Generic Knowledge Management Framework

    Let's recollect the Generic Knowledge Management Framework that we have introduced in chapter 1. Figure 15.1 is taken from chapter 1.

    The four levels of knowledge covering end-to-end knowledge are:

  • • Abstract knowledge: This is knowledge at the highest level of abstraction. It is manifested in universal truth and statement of fact at the highest level.

  • • Domain knowledge: It contains knowledge of the domains such as manufacturing, insurance and banking.

  • • Enterprise knowledge: This is the instantiation of domain knowledge for an organisation such as a banking company.

  • • Project knowledge: It keeps the enterprise knowledge continuously updated.

    • The level of knowledge is contextual and something at abstract knowledge level in one context can be at project knowledge level in another context.

    The respective stakeholders at these levels of knowledge are:

  • • Project knowledge: The project team of the organisation

  • • Enterprise knowledge: The IT and business teams of the organisation

  • • Domain knowledge: College students, for skill development relevant to an organisation

  • • Abstract knowledge: Students, for their basic education

  • The building blocks required to capture knowledge at various levels, as per GKMF are given in Figure 15.2.

    • When we apply this concept to software development, the number of building blocks changes to 18 for project knowledge as shown in Figure 15.3.

  • 4 - Project Knowledge Model: Context and Definition

  • Manoj Kumar Lal
  • Book:
    Knowledge Driven Development
    Published online:
    20 October 2018
    Print publication:
    08 March 2018, pp 59-96

  • Summary

    Project knowledge, which was notionally introduced in the previous chapters, is fully contextualised and defined in this chapter. The chapter begins by explaining what currently happens in the traditional project delivery regarding project knowledge. The complete definition of PKM is provided. At the end, an example of PKM is given to explain how it might look.

    Traditional Project Knowledge Management

    Knowledge, which is the combination of experience and research, is necessary to help IT industry, just as it is for all the other industries. IT industry will have two aspects: domain and technology. Domain is the collective knowledge, driven primarily by processes. Technology has implements such as programming languages that help putting that knowledge into useful outcome, most of the time it is software. Technology primarily helps in automating processes.

    The automation that typically results in creation of software, is delivered via a project or programme. Knowledge plays a crucial role in software development and consists of business and technical knowledge. Typically, a software development project consists of four knowledge-intensive phases. The phases along with the document representing that phase is listed below:

  • 1. Requirement analysis (business knowledge) – Business Requirement Specification Document

  • 2. Solution design (business knowledge) – Functional Specification Document

  • 3. Application design (technical knowledge) – High Level Design Document

  • 4. Test design (business knowledge) – Test Case Document

    • This combination of knowledge is called ‘Project Knowledge’. Let us now understand how the Waterfall and Agile methodologies manage this project knowledge.

    Project Knowledge Management in Waterfall Methodologies: Document Driven

    Project knowledge is managed in the Waterfall methodology using documents. The main documents representing project knowledge are:

  • 1. Business Requirement Specification (BRS) representing requirement analysis.

  • 2. Functional Specification Document (FSD) representing solution design.

  • 3. High Level Design (HLD) representing application design.

  • 4. Test Cases representing test design.

    • Documents are authored by relevant stakeholders and are subject to review by the project team and SMEs, who may or may not be part of the project team. Post review, the documents are singed off and once a document is signed-off, changes to it are managed by version control. The next version of the document is also subject to the review cycle. Every time the next version of the document is signed-off, the information needs to be communicated to the entire project team.

Page 69 of 254