Software Engineering and Development

Summary

As an introduction to white-box testing, the first technique presented shows how to identify lines of code that have not been executed during testing, and how to develop additional tests to ensure that they produce the correct results when executed.

Summary

Application testing is often emphasised in practice, as it ensures that an entire software system works for a user. However, this is substantially more complex than unit-testing, so this topic is addressed after the underlying concepts have been introduced in the previous chapters. As for object-oriented testing, this is a significant topic, and the reader is introduced to the common form used in practice: user-story testing. A worked example is used to present the techniques involved to analyse the software interface and produce a fully automated set of tests for a web-based application. A more detailed analysis follows, identifying many of the more difficult problems that an application tester will experience.

Summary

Testing is an important element in the software development cycle. This chapter examines where software testing fits into a number of software process models: the waterfall model, the V-model, incremental and Agile development, eXtreme Programming, and SCRUM.

Summary

There is a subtle distinction between statements in a program, and the branches between those statements. Even with full statement coverage, faults may remain. This chapter presented shows how to identify branches in the code that have not been taken during testing, and how to develop additional tests to ensure that they produce the correct results when they are taken.

Summary

The book is summarised by reviewingthe topics discussed and practised. It then motivates the software testing process used in the book by tracing all the steps backwards based on the data required by each step. We further provide additional reading material, categoriesed by important topics such as random testing, program proving, testing safety-critical software, etc. The chapter closes with a glimpse into current 'hot' research topics.

Summary

Combinations of different inputs, when not correctly handled, are a frequent cause of faults in software. Decision tables allow the tester to identify these combinations, and further improve the test coverage. Building on the knowledge gained in the previous chapters, this chapter explains how to identify casues and effects, build a decision table, and then use the rules in the table to develop test cases and automated tests.

Written in a tutorial style, this comprehensive guide follows a structured approach explaining cloud techniques, models and platforms. Popular cloud services such as Amazon, Google and Microsoft Azure are explained in the text. The security risks and challenges of cloud computing are discussed in detail with useful examples. Emerging trends including mobile cloud computing and internet of things are discussed in the book for the benefit of the readers. Numerous review questions, multiple choice exercises and case studies facilitate enhanced understanding. This textbook is ideal for undergraduate and graduate students of computer science engineering, and information technology.

This book presents a new methodology, known as Knowledge Driven Development, for managing project knowledge in an exhaustive and structured manner. The text highlights the importance of efficient project delivery methodology in the overall software development life cycle. Important topics such as requirement analysis, solution design, application design, and test design are discussed in depth. It establishes a connection between enterprise knowledge and project knowledge for continuous improvement and accelerated project delivery. Separate chapters on end-to-end project delivery, compliance and protocols and interface with existing methodologies makes it useful for the readers. Several case studies and examples are interspersed throughout the text for better understanding.

This extensively classroom-tested text takes an innovative approach to explaining software testing that defines it as the process of applying a few precise, general-purpose criteria to a structure or model of the software. The book incorporates cutting-edge developments, including techniques to test modern types of software such as OO, web applications, and embedded software. This revised second edition significantly expands coverage of the basics, thoroughly discussing test automaton frameworks, and it adds new, improved examples and numerous exercises. The theory of coverage criteria is carefully and cleanly explained to help students understand concepts before delving into practical applications, while extensive use of the JUnit test framework gives students practical experience in a test framework popular in the industry. Exercises, meanwhile, feature specifically tailored tools that allow students to check their own work. The book's website also offers an instructor's manual, PowerPoint slides, testing tools for students, and example software programs in Java.

Summary

KDD can drive the digitisation of project knowledge that may lead to standardising the processes of the project delivery. This may take the IT industry away from being knowledge-based and nearer to being a process-based industry. The factory model is suited to process-based industries and we can now say that KDD may enable IT industry to follow the factory model. However, changing from the current knowledge-based approach to factory approach is not simple. It needs greater appreciation of the digitisation of the project knowledge and a change in mindset to inspire the project team to work in the factory model. This chapter discusses these two topics in detail: enablement of the factory model for IT industry and the cultural change required to make it happen.

Bringing IT Project Delivery Closer to Process-Based Industry

Traditional project knowledge is contained in the following set of project documents:

Summary

When we think of the challenges in software engineering, we focus on the various technical activities: requirements, architecture, design, implementation, verification etc. Various management dimensions also receive attention: processes, planning, change management, quality, teamwork, competency, domain understanding, customer interaction, value focus and so on. Clearly, each one of these is very important, even critical, to successful software engineering.

However, there is another dimension that is central to software engineering: contextual knowledge and how it flows through the engineering process, into the final product. It is easy to see why this dimension is central if we examine the nature and role of software. Software is the agent of operations for systems. It implements/enables the concept of functioning of its target system, which could be a business function, embedded system and/or user task. The technical activity stream in software engineering as a whole is aimed at developing this contextual knowledge about the target system, and then ensuring that it is addressed accurately and consistently by the resulting software solution.

This book introduces Knowledge Driven Development (KDD), a path-breaking software engineering technology (best practice) that manages and ensures the systematic flow of contextual knowledge into software solution. As the author Manoj Kumar Lal illustrates beautifully through the case studies in Chapter 1, even software projects that diligently follow modern best practices are extremely likely to face challenges associated with managing this flow. The problem is that contextual knowledge evolves continuously as the project progresses (In Agile, this means that knowledge relating to software generated by a particular Sprint continues to evolve even after the Sprint completes), and that consistent shared understanding of relevant contextual knowledge needs to be maintained across all team members (even in large distributed teams) to avoid quality problems. Readers will find that the typical problems described by him are familiar to them as commonplace in the projects that they execute, and that these problems lead to significant productivity losses and quality problems. Every project, large or small, will benefit substantially from a structured approach to managing the consistent flow of contextual knowledge into software solutions.

The book goes on to introduce precisely such a structured approach. Contextual knowledge about the target system is captured through a Project Knowledge Model (PKM) classified into 18 ‘building block’ types, and a further n2matrix of 171 possible relationships among them.

Summary

Generally, there are two types of people in the world: one who follow processes and methodologies as written in books, and the other who enjoy breaking rules and doing things differently. The latter can also be split into two categories: those with good intentions and those with bad intentions. The first category produces innovation and the second category produces criminal behaviour. Society has all these kinds of people. In a healthy society, a majority of people follow processes, some have honourable intentions in breaking rules and only a very few have criminal intentions.

This is evident in software project delivery as well. Let's see how it happens there. Almost all projects select a project delivery methodology (there are many to choose from). There will be a set of people in the project who will understand the intent of the methodology and try to follow it while performing their assigned tasks. There will be another set of people who will have the maturity to understand that certain portions of the project delivery can be better accomplished by slightly tweaking the methodology steps and they will propose this to their colleagues. There will also be a few people who, for less honest reasons, will argue against the methodology steps or suggestions for change. They might propose something that will make their task easier, even if it becomes difficult for the majority of the team to accommodate their proposal. They will take excuses of someone's failure and justify delays from their side. They will create an opaque boundary around their work so that the transparency in the project progress is hindered.

While there may be a majority of people falling under type one (process followers), there are significant number of people falling under the second type, category one (rule breakers with good intentions) and category two (rule breakers with bad or selfish intentions). A fine balance between all these types of people needs to be maintained by the project management. That is why success and failure of a project today is largely in the hands of the project manager, even if the team is highly skilled and experienced.

Depending only on the project management to drive a project is not the best solution. The industry is keen to solve this issue at a strategic level. A major roadblock is that the IT industry is still knowledge-intensive.

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:

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.

Software Engineering and Development

Refine search

Refine search

Actions for selected content:

1810 results in Software Engineering and Development

Preface

5 - Statement Coverage

Summary

10 - Application Testing

Summary

13 - Testing in the Software Process

Summary

6 - Branch Coverage

Summary

14 - Wrap Up

Summary

Appendix: Running the Examples

4 - Decision Table Testing

Summary

Frontmatter

Cloud Computing

Knowledge Driven Development

Introduction to Software Testing

14 - Suits Factory Model: Needs Cultural Change

Summary

Foreword

Summary

Overview of the Book

Summary

References

Dedication

8 - Extended KDD: Pre-Requirement and Post Delivery

Summary

Appendix E - KDD: Response to Criticism

Summary

Appendix B - Compliance of PKM with GKMF

Software Engineering and Development

Refine search

Refine search

Actions for selected content:

Save Search

1810 results in Software Engineering and Development

Summary

Summary

Summary

Summary

Summary

Summary

Cloud Computing

Knowledge Driven Development

Introduction to Software Testing

Summary

Summary

Summary

Summary

Summary