Which of the following was described as the main drawback to the waterfall software development model?

Waterfall

The waterfall methodology uses a sequential or linear approach to software development. The project is broken down into a sequence of tasks, with the highest level grouping referred to as phases. A true waterfall approach requires phases that are completed in sequence and have formal exit criteria, typically a sign-off by the project stakeholders. A typical list of waterfall tasks would include:

Scope and plan project

Gather and document requirements

Design application

Develop application and perform unit tests

Conduct system testing

Perform UAT

Fix application as appropriate

Deploy application

The waterfall methodology is a formal process, with each phase comprising a list of detail tasks with accompanying documentation and exit criteria. Larger enterprises often require the use of SDLC methodology products, particularly in larger IT application projects. This is also the approach that SIs use when building IT applications for their customers, since budget, resources, deliverables, and scope have to be managed on a very disciplined basis.

The advantages of the waterfall methodology are that:

Requirements are completed early in the project, enabling the team to define the entire project scope, create a complete schedule, and design the overall application.

It improves resource utilization because tasks can be split to be worked in parallel or grouped to leverage resource skills.

It is a better application design because there is a more complete understanding of all the requirements and deliverables.

The project status is more easily measured based on a complete schedule and resource plan.

The disadvantages of the waterfall methodology are that:

It is often difficult, particularly in BI, to get complete business requirements up front in a project, because business people have not really thought through in detail what they need, and business requirements can change during the project.

It requires a very detailed breakdown of the tasks and deliverables for the overall BI application, which may be beyond the project team’s capability or experience at the start of the project.

Although waterfall projects do not inherently have to span lengthy periods of time, it is very common for these projects to span months or quarters because of the emphasis on trying to get everything done at one time, i.e., the “big bang” approach. The likelihood of projects being late, over budget, and failing to meet expectations rises as the timeframe for an IT project significantly increases.

Traditional Waterfall Methodology

Traditional waterfall methodologies incur too much cost, rework, and risk to be effective in the dynamic field of information management. ROI tends to be delayed too long. Agile methodologies balance out the risk (and reward) over time. Some of the ways SCRUM does this is through taking “how do we handle this?” questions off the table. To a very high degree, everyone knowing the rules of the game makes for a much better game. But, you say, all methodologies do this. True, good ones do, but let me expose the elements of SCRUM that make it balanced.

We must maintain a balance between rigor and creativity (see Figure 16.2 “Unbalanced Methodologies”). That’s where leadership and judgment come into play and no methodology will ever replace that! Any methodology that claims you just put the people into place and it works without major decision making along the way, is folly. As I discuss agile approaches, and SCRUM in particular, please note I am not discounting the need for leadership and judgment in the process.

Silver bullet, or special tool for the innovator niche? Agile in the enterprise world

Despite the frustration of both IT executives and professionals with the waterfall methodology and its “big bang—big crash” integration shock, it is still the predominant project execution model in the enterprise world.11 Agile methodology has gained a foothold there, but it still resides in a niche. Common wisdom (outside the agile community) considers it to be mainly suited for innovative projects with limited cost pressure,12 although there is some indication that adoption of agile methods generally results in a productivity gain.13 All in all, agile techniques meet several obstacles in the enterprise world:

Scaling. Agile techniques have their roots in rather small-scale projects and have been designed, in their original form, for a developer team with up to roughly 10 members. There are methods for scaling agile methods to larger teams and multisite development (see, for instance, Larman and Vodde, 2009; Cockburn, 2007; or Leffingwell, 2011). But one must be aware that scaling agility is a less well-trodden path than running large programs in waterfall mode and should not be attempted without guidance from process experts. Another challenge lies in the agile methodology's rather hands-on attitude toward software architecture—a topic of special importance for large and complex software systems. We will look at this issue in depth later.

Testing. The agile methodology has a strong affinity for test automation. If the quality assurance of an enterprise mainly relies on managing manually executed test cases, agile concepts are harder to put into practice. In addition, there are areas such as performance tests, load tests, and stability tests where continuous testing work (as preferred by agile methods) is not economically feasible. This requires a reconciliation of the agile testing paradigm with classical waterfall planning and execution of test phases and milestones.

Role definitions. The individual work and its results are frankly exposed to the whole team, in practices like pair programming or by continuous integration, which immediately drags one's contributions and faults onto the stage. Perfectionists have to learn to provide simple solutions and enhance the design only upon stakeholder requests. In addition, agile techniques do not value titles much; instead of being “senior specialist” (or any other shiny job designation), the only honest title for an agile developer can be “team member.”

Organizational resistance, process incompatibilities, and culture clash. Introducing agile practices can meet a whole range of defense mechanisms. One can expect a certain clash between the agile activity and the enterprise culture. “To some, this [agile] scenario may appear to be unsupervised, chaotic, and even unprofessional (…). [T]he combination of casual dress, pairing, constant communication, and stuff stuck all over the walls does not fly well in some corporate circles,” writes Leffingwell (2007, p. 90). The agile methodology's egalitarian spirit is to some extent orthogonal to hierarchical thinking and structures in more conservative enterprises. All of a sudden, the project manager can no longer give commitments without the consent of the team. Agile projects demand constant stakeholder attention and contribution—the good old “create a package and throw it over the fence” mentality doesn't work anymore. Buyers need to give up the illusion that they can create a requirement specification and get the perfect solution back without any additional contribution. Many more examples can be found. In some cases, the friction results from a “we always did it this way” mentality. In others, agile methods uncover hidden omissions and problems in an organization's processes.

Outsourcing. Outsourcing of agile projects is possible, but it presents considerable obstacles. First, agile methods are easiest to implement in a time-and-material contract model, which often clashes with budgeting and procurement policies. The preferred outsourcing model (fixed-price projects with detailed requirements specified up front) is in conflict with the agile methodology's principle of local planning and welcoming change.14 Second, especially when it is an offshoring project, agile projects cause a wide range of problems that require a lot of management commitment and process expertise (on both supplier and buyer side) to overcome.15 However, one should be careful not to condemn agile methods as unsuitable for outsourcing and offshoring. Agile methods are simply less often practiced than waterfall methods. The waterfall methodology is not inherently better; everyone in business knows many stories of failed outsourcing projects.

Budget planning. The budget-planning process of an enterprise typically takes quite some time. In particular, funding for larger projects requires at least a year, and promoters of a project candidate must put a reliable price tag on it in advance and convince the sponsors of its business value. The board will likely reject project proposals, stating, “We'll start off agile with N developers, and let's see where we end.” An agile project will only have a chance to be approved with a precise effort estimation and a project road map in the granularity of epics describing the project's target.

Agile techniques often enter an enterprise through the back door, as a niche methodology used in handpicked innovation or pilot projects. Despite the obstacles, there is a lot of enterprise interest in agile methods, indicating that the adoption rate will further increase beyond that niche.

4 Conclusions and future work

This chapter presents heartbeat signal from face video as a new biometric characteristic for person verification. Using the Transformation matrix on a waterfall methodology of the reproduced HSFV, features were extracted. The bilateral Minkowski distances were derived as features from the Radon picture. A decision tree-based supervised method was used for authentication. The suggested biometric, as well as its authentication mechanism, proved its biometric recognition capability. However, a number of problems must be investigated and resolved before this biometric may be used in real systems. For example, in a real scenario, it is required to establish the effective length of a video that may be taken for authentication. By managing the face spoofing, combining face with HSFV may generate intriguing results. Processing time, characteristic optimization to decrease the disparity between accuracy and acceptance rate, and experimenting with alternative metrics for computing the matching score are all things that must be looked at. These might be potential future areas for expanding on the existing research.

Why Does Continuous Architecture Work?

We strongly believe that leveraging the contents of our “Continuous Architecture” toolbox will help architects address and eliminate the bottlenecks that may be created by traditional architecture methodologies when they attempt to support projects using Agile development. In addition, the Continuous Architecture approach speeds up the software development and delivery processes by systematically applying an architecture perspective and discipline continuously throughout the development process. This supports our goal of delivering software at an ever-increasing speed to create competitive differentiators.

As Kurt Bittner notes in the Preface to this book, Agile development is now “old news,” and older Iterative, Incremental, and “Waterfall” ways of developing software have faded from the leading edge of software development. As older applications are replaced, refactored, or retired, these older methodologies are losing their grip on software developers. In the meantime, Agile is evolving thanks to the concepts of DevOps and Continuous Delivery, and software architecture is catching up by changing its old methodologies into modern approaches such as Continuous Architecture. Each of these approaches, processes, and methodologies—Agile, DevOps, Continuous Delivery, and Continuous Architecture—can be thought of as pieces of a software delivery puzzle (Figure 11.1).

One of the main reasons why the Continuous Architecture approach works is that we do not think of it as a formal methodology. There is no preset order or process to follow for using the Continuous Architecture principles, tools, techniques, and ideas, and you may choose to use only some of them depending on the context of the project you are working on. We have found that using this toolbox is very effective in our projects and that the Continuous Architecture tools are dynamic and adaptable in nature. These tools were built and fine tuned from our experience with real projects and our work with other practitioners. They are practical, not theoretical or academic. They enable the architect to help software development teams create successful software that implements key Quality Attributes such as modularity, maintainability, scalability, security, and adaptability.

Unlike most traditional software architecture approaches that focus on the software design and construction aspects of the Software Delivery Life Cycle, Continuous Architecture brings an architecture perspective to the overall process, as illustrated by Principle 5: Architect for build, test, and deploy. It encourages the architect to avoid the Big Architecture up Front (BArF) syndrome when software developers wait and do not produce any software while the architecture team creates complicated and arcane artifacts describing complex technical capabilities and features that may never get used. It helps the architect create flexible, adaptable, and nimble architectures that are quickly implemented into executable code that can be rapidly tested and deployed to production so that the users of the system can provide useful feedback, which is the ultimate validation of an architecture.

We also realize that some companies may not be ready to adopt Agile software development methodologies. Moreover, even if a company is fully committed to Agile methodologies, there may be situations such as working with a third-party software package when other approaches such as Iterative, Incremental, or even “Waterfall” may be more appropriate.

One of the key benefits of our “toolbox” approach is that its contents can be easily adapted to work with Iterative or Incremental instead of Agile and even to projects following a Waterfall methodology, and therefore even Agile is not a prerequisite to using the Continuous Architecture approach. We still recommend using Agile to deliver software rapidly, but the Continuous Architecture approach will still yield important benefits when used with other software development methodologies.

The Value of Architecture

What is the real value of architecture? We think of architecture as an enabler for the delivery of valuable software. Software architecture’s concerns, quality attribute requirements such as performance, maintainability, scalability, and security, are at the heart of what makes software successful.

A comparison to building architecture may help illustrate this concept. Stone arches are one of the most successful building architecture constructs. Numerous bridges built by the Romans around 2000 years ago using stone arches are still standing, for example, the Pont du Gard, built in the first century ad. How were stone arches being built at that time? A wooden frame known as the “centring” was first constructed in the shape of an arch. The stone work was built up around the frame, and finally a keystone was set in position. The key stone gave the arch strength and rigidity. The wood frame could then be removed and the arch was left in position. The same technique was later used in 1825--28 by Thomas Telford for building the Over Bridge in Cloucester, England (Figure 11.2).

We think of software architecture as the “centring” for building successful software “arches.” When Romans built bridges using this technique, we do not believe that anybody worried about the aesthetics or the appearance of the “centring.” Its purpose was the delivery of a robust, strong, reliable, usable, and long-lasting bridge.

Similarly, we believe that the value of software architecture should be measured by the success of the software it is helping to deliver, not by the quality of its artifacts. Sometimes, architects use the term “value-evident architecture” to describe a set of software architecture documents they created and are really proud of and that development teams should not (ideally) need to be convinced to implement the architecture. However, we are somewhat skeptical about these claims; can you really evaluate a “centring” until the arch is complete, the key stone has been put in place, and the bridge can be used safely?

Data conversion life cycle

The basic systems development life cycle for a data conversion project is the same as for any application development endeavor, with activity centered around planning, analysis, requirements, development, testing, and implementation. A pure “waterfall” methodology is not implied or necessary. Like other data-related projects, the activities in the analysis phase should include profiling the data in the source and target data structures. The requirements phase should include verifying that the assumptions made are true by trying the load of very small amounts of data. Unlike application development projects, there is no support phase in the data conversion life cycle, unless additional data sources are to be loaded to the target application later, such as when multiple systems are being consolidated over time, data is being moved from one system to another in phases, or an organizational merger or acquisition takes place.

Extended Project Team

The extended project team handles several functions required by the project that occur at discrete times and that are performed by people outside of the core development team. The extended team encompasses three primary roles:

Players—A group of business customers are signed up to “play with” or test the BI analytics and reports as they are developed to provide feedback to the core development team. BI solutions developed in an iterative and interactive fashion, often leveraging agile development techniques consistently yield higher business value and adoption than the “old school” waterfall methodology. This is a virtual team that provides focused attention during specific periods of the project. Since business peoples’ time is valuable, it is necessary to schedule these times and get business management to commit to allocating people to these tasks. Communication of project status and any scheduling changes must be managed by the BI project leader.

Testers—A group is gathered, similar to the virtual team just mentioned, to perform more extensive QA testing of the BI analytics, ETL processes and overall systems testing. You may have project members test other members’ work, such as the ETL team test the BI analytics and vice versa. Other groups that are often asked to participate are the source system experts to verify DI processes, and BI consumers, particularly “power users,” to validate BI applications. These tests include usability, but more importantly are used to reconcile data from source systems and compare results with any legacy reporting systems or data shadow systems.

Operators—IT operations is often separated from the development team, but it is critical that they are involved from the beginning of the project to ensure that the systems are developed and deployed within your company’s infrastructure. Key functions are database administration, systems administration, and networks. In addition, this extended team may also include help desk and training resources if they are usually provided outside of development.

Non-Waterfall Development Methodologies

The steps that we’ve been discussing so far in this section align more closely with the waterfall method of application development rather than other methodologies which may be in use. Many companies are finding value through the use of Agile, Iterative, Extreme Programming, and other alternate development methodologies. This book is not intended to be a debate as to which methodology is the best or even which one works best under different circumstances. Instead, we have chosen to illustrate the enterprise applications administration tasks and roles associated with the waterfall development methodology because those same tasks and roles exist within all development methodologies but with different timing and methods of interacting.

Whereas with the waterfall methodology there are distinct phases that a project goes through such as scoping, design, development, testing, and deployment, in other development methodologies these phases work very differently. For example, in the Agile methodology, development work occurs in rapid “sprints” that occur over a relatively short amount of time such as 1–2 weeks. The goal of each sprint is to create a specific feature that can then be deployed and demonstrated to the requesting business unit. To support this, there are different steps that have to be done within the implementation process to support the rapid-fire approach of development that must be done in order to quickly design, build, test, and deploy these features.

The role of the enterprise applications administrator in these alternative methodologies doesn’t really change, but the way that they engage may. For example, the nonfunctional requirements that the administrator works with the developers on during the scoping phase may turn into “stories” that define what needs to be built within an Agile methodology. In essence, the same work has to be done from the enterprise applications administrator perspective; it just may have to be done in a slightly different way to support the organization’s chosen method of performing development and project implementations.

3.3.2 Agile Roles

Actors and stakeholders in an Agile project come together in a unique way that is a departure from traditional workflows. For companies in transition from waterfall to Agile, User Stories can follow an acceptance criteria and function like small, manageable requirements. Any User Story implemented in a product has several components that demand different expertise from a multispecialized team, which can be either contained in different departments or, optimally, working exclusively together on given parts of the product. In this setting, global strategy is a concern from the get-go thanks to constant involvement with the core design and development teams, as well as the product stakeholders. Project management duties are distributed and the Product Owner’s vision is instrumental in the whole process.

The naming of roles often varies between different Agile methodologies, but some commonalities can be identified.

Customer

It can be a combination of the Product Owner and the end-customer. They specify the product requirements, regardless of the actual final plan.

Product Owner

Fulfills a similar role to the classical perception of the Product Manager in waterfall methodologies:

creating and collecting the general requirements of the project,

establishing clear objectives for ROI,

releasing schedule,

having responsibility over the Product Backlog prioritization and management.

Scrum Master

The role drives and supports the work developed by the team, helping the team to overcome potential obstacles to completing the project stages. The role is of the main facilitator and implementing the process for the whole team.

An iteration typically lasts 1–4 weeks and has four distinct phases:

Planning

The preparation of the project involves prioritizing and handling items in the Product Backlog that will be implemented during the iteration, in case one is used. For noniterative approaches like Kanban, the team gets together regularly to review and plan the next batch of items to be implemented. Normally, if the iterative model is used, it should have a clear theme or goal.

This is where the UX teams can be most influential. Insights from research and preparation for both visual and experience design set the stage for development for implementation. This is also where user testing can be most useful, working on hypothesis and implementation ideas before.

Development

During the Development phase, there is also a daily status meeting known as the daily stand-up. In this meeting, each team member states what they did the previous day, what they are going to do today, and identifies any existing or foreseeable roadblocks.

Review

When the iteration nears completion, a review meeting is held with all stakeholders to demonstrate the new software and receive feedback on it and the functionality that has been developed.

Retrospective

The last phase, or Retrospective, is a postmortem for the team to discuss how the process could be improved.

Localization and design are not separate worlds. Text is an essential part of a complete multimedia system that includes image and text. Visually and linguistically, text plays a major role in the user’s perception of a product. The most refined and sophisticated UX can be wrecked by careless localization and haunted by issues and bugs. Fonts are lost, carefully complimentary labels suddenly appear juxtaposed, HTML is improperly adapted to target locales: all are little product nightmares that can only be countered by a combined approach that makes UX and localization part of the same combination.

Therefore, internationalization is key to a consistent UX in a multilingual product. Internationalization defines the set of processes and techniques that are implicated in making a product capable of adaptation to different cultures. This is where UX implementation is at its trickiest. No sound internationalization-friendly design can be adequately implemented without an accurate study of localization prioritization. You must define which languages and cultures you want to localize into and include both immediate priorities and future plans. This will enable you to optimize layouts for culturally sensitive graphics and indications or—optimally—to change requirements in the light of new market strategies.

I. Design, Code, and Test in the Software Development Life Cycle

Development methodologies for software projects have evolved from a highly structured, end-to-end process into more flexible, iterative processes. In the 1960s when data processing was in its infancy, programs had features termed “spaghetti code” and programming languages had statements including GOTO that enabled programmers to jump anywhere they liked in the programming logic. As a result, software was hard to understand, develop, and maintain. A need arose for a more rigorous methodology in development of software. To compensate for the lack of logic and rigor, modular, hierarchical techniques were created and the software development life cycle (SDLC) was introduced.

The life cycle ensured that a defined process was followed in the development of software applications. Software development was divided into several independent phases known as the SDLC. Specifically, the phases are Requirements, Analysis, Design, Code, Test, and Maintenance as shown in Fig. 1.

With the traditional methodology, each phase is an independent, isolated activity. One phase has to be completed before the next phase begins. This methodology is termed waterfall, because phases “trickle down” into one another until the application is developed. The structured, inflexible nature of this methodology created problems with software development. Waterfall methodology fails to provide feedback between phases of development. At the onset, the requirements are set in stone. After analysis is per formed, no newly discovered knowledge can be used o improve the requirements. Similarly, after design is done, analysis cannot be changed without great exception. Often, by the time a project was complete, technology had advanced, requirements had changed, and the people who once approved the requirements had moved on to better jobs. The result was the development of systems that failed to meet users needs. Often these projects were plagued with cost and schedule overruns.

Continual problems with cost overruns and late de liveries caused the software industry to examine the life cycle and come up with ways to improve software quality by inventing more flexible methodologies. The need for involving the user throughout the life cycle and the need to mitigate risk by breaking systems development into smaller subsystems became apparent. To make the waterfall methodology less risky, systems were broken into smaller functional units and then integrated as a later phase of the life cycle. However, phased development and implementation still had many of the same problems with inflexibility. A new methodology was needed to build software in such a way that changes in design could be easily achieved without burdening other components of the system. Rapid prototyping methodology and spiral development arose to replace traditional development. The development of object oriented languages and graphical user interfaces directly fit the new methodologies.

The iterative or spiral development life cycle introduced by Boehm in 1988, shown in Fig. 2, was adopted to overcome the shortcomings of the traditional waterfall method. Instead of each phase being independent, phases provide feedback and are reiterated until the design is complete. During each iteration of the prototype, functionality is added and increasingly the users needs are implemented. Requirements are flexible at the beginning and become more defined as development continues. This more flexible approach al lows new and better knowledge to be integrated during the development rather than waiting until the end of the life cycle and doing it as part of maintenance.

Having a flexible methodology allows developers to apply new knowledge to the software design as it becomes known. This creates a better solution to the problem, prior to implementation. This is a preferable way to operate for two reasons. First, it ensures that the user's needs are met. Second, it is far less expensive to improve a solution during the early stages of a project rather than after the program is deployed.

However, poor quality can exist with iterative and traditional methodologies. It is necessary to control the software development process in a way that ensures the quality of more reliable, maintainable, expandable systems. Rigorous design, code, and test are all essential to the development of quality software. Understanding and managing these processes helps to better understand and meet customer's requirements. It is also imperative that the customer be involved during the development process so their feedback can directly improve the design.