Software Design Challenges
Carlos E. Otero
Today, the software design phase has evolved from an ad-hoc, and sometimes overlooked phase, to an essential phase of the development life-cycle. Furthermore, the increasing complexity of today’s systems has created a set of particular challenges that makes it hard for software engineers to meet the continuous customer demand for higher software quality. These challenges have prompted software engineers to pay closer attention to the design process to better understand, apply, and promulgate well known design principles, processes, and professional practices to overcome these challenges. Some of the major challenges include requirements volatility, design process, quality issues (e.g., performance, usability, security, etc.), distributed software development, efficient allocation of human resources to development tasks, limited budgets, unreasonable expectations and schedules, fast-changing technology, and accurate transformation from software requirement to a software product. A brief discussion of these challenges is presented below.
Design Challenge #1: Requirements Volatility
A major reason for the complexity of software projects is the constant change of requirements. When designed properly, software can be modified or extended easily; however, when designed poorly, modifying software can become overwhelming and lead to all sorts of complex problems. Unlike the development of computer hardware, bridges, houses, or mechanical parts, software's very own nature allows itself to change to provide different or new functionality to systems. This same trait that makes software so desirable is what makes it also so complex. Although much effort is put in the requirements phase to ensure that requirements are complete and consistent, rarely that is the case; leaving the software design phase as the most influential one when it comes to minimizing the effects of new or changing requirements. Requirements volatility is challenging because they impact future or already going development efforts. This forces designers to create designs that provide solutions to problems at a given state while also anticipating changes and accommodating them with minimal effort. This requires designers to have a strong understanding of the principles of software design and develop skills to manage complexity and change in software development.
Design Challenge #2: The Process
Software Engineering is a process oriented field. Software processes allows engineers to organize the steps required to develop software solutions with schedule and cost constraints. Therefore, at the core of every software development company, there should be a sound, well understood, and consistent process for software development. Processes can also be developed and customized for particular phases of the software engineering life-cycle. In the design phase, software processes involve a broad set of activities and tasks that bridge the gap between requirements and construction while adhering to a set of project-specific (or company-specific) constraints. These activities include common ones, such as architectural and detailed design, as well as other supporting management activities. These supporting activities include establishing a design review process, defining design quality evaluation criteria, evaluating design reuse, establishing design change management and version control procedures, design tool adoption, resource allocation, and others. In many cases, a company’s design process is not well established, poorly understood, or approached with minimalistic expectations that ignore aspects that are essential to executing a successful design phase. Focusing design efforts on creating independent software products, such as a simple class diagram or user interface, while ignoring other design activities may create complexities later on during system’s test and maintenance. The design process is challenging because essential design process activities are often overlooked, done in an ad-hoc manner, or simply not done at all. In many cases, a well established and carried out design process serves an indication of future project's success.
Design Challenge #3: The Technology
Software is meant to be everywhere. From healthcare systems, education, defense, and everyday ubiquitous devices, software is required to operate on a massive and always evolving technology landscape. Besides the operating environment, the technology for designing and implementing today's software systems continues to evolve to provide improved capabilities. Examples of these include modeling languages and tools, programming languages, development environments, design patterns, and design strategies. As new technologies emerge, software engineers are required to assimilate and employ them all at the same time. In some cases, emerging technologies do not completely replace old ones. Some software systems are required to interoperate with old legacy systems designed with older design methodologies. This results in software designers employing a myriad of design methodologies and technologies, all on the same software system. In other cases, design models need to be derived from existing code, modified, and made interoperable with newer technologies. This technology-driven aspect of the design phase creates a demand for capable software designers that can assimilate new technology quickly and effectively in order to succeed at designing software. The technology aspect of software design is challenging because it is fast and ever-changing, therefore designers must keep abreast of the latest advances and become proficient in the application of these advancements while maintaining rooted in legacy technology.
Design Challenge #4: The Ethical and Professional Practices
Designers create blueprints that drive the construction of the software. During this creation process, designers are required to determine how design decisions affect the environment and the people that use the software. In many cases, the software development process is traditionally carried out under tight schedule constraints. Inherently, all phases of the development life-cycle suffer from this, including the design phase. This creates external pressures that can lead designers to deviate from the normal design approach to meet these demands, which can have catastrophic consequences. No matter how tight deadlines are, how much animosity exists within the design team, or how much other external/personal factors are brought into the design phase, software designers must exhibit strong ethical and professional practices to ensure that the systems they build are of highest quality and that all design considerations are properly evaluated. In many cases, this requires designers to exert strong leadership skills to influence and negotiate with stakeholders, motivate the design team, and lead the design process to accomplish the project’s goals. Designers are also responsible for enforcing ethical guidelines during the design process; evaluating the social impacts of their designs in the public domain, or in safety-critical systems; and to follow the appropriate professional practices to ensure success in the overall system. The ethical and professional practices aspect of software design are challenging because designers are constantly faced with numerous pressures from stakeholders that influence designers' decisions, most of which have consequences of social, ethical, or professional nature.
Design Challenge #5: Managing Design Influences
Designs are shaped by many different influences from stakeholders, the development organization, and other factors. These influences can have cyclical effects between the system and its external influences, such that external factors affect the development of the system and the system affects its external factors (Bass, Clements and Kazman 2003) . Managing these influences is essential for maximizing the quality of systems and their related influence on future business opportunities. Of specific importance are design influences that come from the system stakeholders and its developing organization.
Designing software is a nondeterministic activity. If given the same task to different designers, different solutions will be proposed, each of them being perfectly acceptable (McConnell 2004). Now add to the mix the multitude of influences that come from different stakeholders and you can easily get a variety of design alternatives for meeting a variety of stakeholders’ concerns, all conflicting with each other. This creates a challenge when trading-off design alternatives that meets all stakeholders concerns. Making such design trade-offs is difficult, especially on large-scale design efforts. Consider a project with multiple customers, each with conflicting goals affecting design decisions. In such project, creating a design that sacrifices some desired customer capability, but provides other desired properties, such as quick time-to-market, reliability, or lower cost can lead to the development of a high-quality system that maintains acceptable levels of satisfaction among stakeholders. This is an example of how stakeholders affect design decision, and the design, in turn, influences the stakeholder’s goals (Bass, Clements and Kazman 2003). Managing stakeholders’ influences are challenging because they require designers to exert a high-level of communication, negotiation, and technical skills to ensure that design decisions are made to accommodate all concerns without negatively affecting the project.
Development Organization’s Structure
The development organization’s structure influences the development of software products, in particular, the design of those products. As example, consider the case of distributed software engineering. In today's global market, more and more cases of distributed software development are taking place. A wide variety of reasons exists for developing software at different sites. Consider companies that have sites in multiple states, where various levels of domain expertise are found at different sites. Or, consider the case of software engineers resigning, creating a gap in the development team hard to fill with local resources. Finally, consider companies that simply want to reduce cost by hiring software engineers from different countries. These and many other reasons exist for having development across site boundaries. In each of these cases, the structure of the development’s organization makes is complicated to coordinate design efforts, evaluate and discuss design alternatives, conduct peer reviews, manage version control, etc. In these cases, designers not only need to consider technical aspects of the design, but the distribution of employees, organizational goals, resource-availability, etc. Designs that support integration of distributed expertise across sites can introduce capabilities for building new software products that could not be engineered otherwise. This in turn, can influence the developing organization to target new areas of businesses, therefore allowing the software design to influence its business goals. Managing the influences of the development organization is challenging because it requires designers to span out of the technical domain to have a keen interests on the organization as a whole.
Bass, Len, Paul Clements, and Rick Kazman. Software Architecture in Practice, 2nd Edition. Addison-Wesley, 2003.
McConnell, Steve. Code Complete, 2nd Edition. Microsoft Press, 2004.
Read more IT Performance Improvement
Certain names and logos on this page and others may constitute trademarks, servicemarks, or tradenames of
Taylor & Francis LLC. Copyright © 20082012 Taylor & Francis LLC. All rights reserved.