Question

Give at least 10 design constraints in software system with some explanation.

Give at least 10 design constraints in software system with some explanation.

Homework Answers

Answer #1


In software architecture design, constraints come in two basic flavors - technical and business. On most projects there are only a handful of constraints, but these constraints are a highly influential architectural driver. Constraints, as the dictionary definition above indicates, are a limiting factor and severely restrict options for making design decisions. They are also fixed design decisions that cannot be changed and must be satisfied. You could think of constraints as the ultimate non-negotiable, "must have" requirement. It is for this reason that architecture design constraints must be created and accepted with care.


Anthony Lattanze of Carnegie Mellon University, author of the Architecture Centric Design Methodology and one of the ATAM creators, likens design constraints in software architecture to "load bearing walls" employed in traditional building architecture. Load bearing walls of a building are extremely strategic and strongly influence the shape and form of the building. What's more, once these essential walls are placed and bearing weight it becomes cost prohibitive to move them.

Technical and business constraints are similarly load bearing. Many design decisions will hang on fixed constraints, further cementing them into your system's design. Adding a component or even refactoring architectural styles might be costly but it can still be done. Deciding to jump from .Net to the JVM requires demolition and rebuilding.

As architecture design constraints are so important it's worth taking some time to understand them in greater detail so you can properly deal with them when they arise.

Technical Constraints in Software Architecture

Technical constraints are fixed technical design decisions that absolutely cannot be changed. Most often technical constraints are provided by stakeholders (perhaps after some digging) at the outset of the project. Sometimes a team may choose to create a constraint, perhaps to simplify the world in which they are working. Regardless of the origin, these architecture drivers are technical in nature and are considered unchangeable and indeed very soon become so.

There are many common examples of technical constraints that you've likely seen.

Programming language - often times a specific programming language will be required for various reasons. For example, the customer may be a Java or Ruby or Microsoft shop. You might simply prefer a certain language over another, or have specific expertise that dictates using a particular programming language. Nearly always, once you've picked a language you are stuck with that choice for the remainder of the project,

Operating system or platforms supported - It must work on Windows, or Linux, or iOS, or Qt on Solaris, or IE 6 on Windows XP, or ... building software that does not satisfy the platform constraint means you have failed to design a software system that satisfies stakeholders' key concerns.

Use of a specific library or framework - Sometimes a specific library might be required to be used. The specific origin might come from the business but the influence is very technical. A common example at many companies is the use of specific open source libraries. Some companies might require that open source always be used. Other companies, might have an approved list indicating which open source software may be used. An interesting example at IBM is that we are required to target the "Blue" JVM, IBM's JDK for all JVM-based projects.

Business Constraints

Business constraints are unchangeable business decisions that in some way restrict the software architecture design. Business constraints are similar to technical constraints in that they are decisions that cannot be changed, but rather than influencing structures directly through technology, the influence occurs indirectly through business decisions. It might be easiest to discuss some examples.

Schedule - "We have to be ready to demo at the trade-show in November." The final delivery date is fixed based on input from the business and cannot be changed. It is now up to you to design a system that can be built within the required schedule.

Budget - I've found that this is less true for product development, but nearly every development contractor must learn to deal with budget constraints. In some cases you might be able to increase the budget, but often budgets, whether fixed through contract or expectations, become constraints on the project and team building the software.

Team composition and make-up - In some cases there may be requirements that specific personnel be used or not used during project. For example, someone may be unavailable, already committed to another project or you may be required to include specific individuals, perhaps for training purposes.

Software licensing restrictions or requirements - Often times you will be required to use specific software components because they are already owned. I've also seen situations where components have been used in very... interesting... ways to satisfy specific licensing restrictions. Legal considerations are extremely constraining.

Identifying Constraints

Constraints originate from a variety of sources. In my experience, more often than not at least one stakeholder has a specific concern that will result in a constraint. For example, the business line or some other stakeholder might decide that IE6 running on Windows XP must be supported (and in spite of our resistance it remains a requirement). If you've ever created a web application for a federal agency of the US Government then you'd know that this was a constraint on all web projects until very recently. United States law requires support of a specific operating system and browser. Period. That changes when Congress passes a new law.

Constraints can also be created before a project even starts, during procurement. In my previous role at IBM as an application engineer / consultant with expertise in the Watson Explorer platform (a/k/a Vivisimo Velocity or Data Explorer), every project on which I worked was constrained to use the Watson Explorer platform. As a consultant I was only brought in once the decision had been made to purchase and deploy Watson Explorer. This constraint is fixed during the pre-sales and sales phase of the system.

It's common that quality attributes and functional requirements will be offered up as constraints. It is a huge mistake to treat a quality attribute as a constraint, even one that is extremely high priority. Quality attributes are NEVER constraints.
When starting a project I advise teams and teammates to be very conservative when fixing constraints. Challenge constraints. Do not accept them lightly. Is this requirement an absolute must-have or is it just extremely important? Is the decision a strong suggestion or a threshold of success for the system?

Over time, design decisions you've made can become constraining but it's important to distinguish between the constraints you are given and the constraints you've created for yourself. Ultimately, the constraints you give yourself can change if you need them to while constraints you are given are non-negotiable. This is why constraints should be considered a distinct architectural driver and tracked explicitly from quality attributes, functional requirements, and specific design decisions.

Know the answer?
Your Answer:

Post as a guest

Your Name:

What's your source?

Earn Coins

Coins can be redeemed for fabulous gifts.

Not the answer you're looking for?
Ask your own homework help question
Similar Questions
Software processes Give at least three reasons for your answer based on the type of system...
Software processes Give at least three reasons for your answer based on the type of system being developed, suggest the most appropriate generic software process model that might be used as a basis for managing the development of the following system A self-driven car Monitoring WAN Circuits Patch software for OS Hotel reservations app
Give a detailed explanation of the software development life cycle?
Give a detailed explanation of the software development life cycle?
good day to you i need a full explanation in Software Construction, Design and Architecture for...
good day to you i need a full explanation in Software Construction, Design and Architecture for these Design Patterns Creational Structural Behavioral Concurrency
1- How software design is a consistent approach and list at least four design challenges 2-...
1- How software design is a consistent approach and list at least four design challenges 2- There are many planning ideas and decisions by managers that are not accepted by team members due to the complexity of change in project planning stage. What should you do?
What are some of the factors used in flexibility options,if you are a software design company?
What are some of the factors used in flexibility options,if you are a software design company?
What is the difference between factorial design and OFAT Give your explanation with example.
What is the difference between factorial design and OFAT Give your explanation with example.
Coupling and cohesion are design concepts that software engineers must consider seriously during software development: Which...
Coupling and cohesion are design concepts that software engineers must consider seriously during software development: Which type of coupling would you consider to be most desirable. Give reasons      [6] Which type of cohesion would you consider to be most desirable. Give reasons      [6] Define software reuse and explain its benefits in software development                  [8] Question three Explain how COCOMO is used in software development                                         [10]
System security; discuss software and hard system securities. Give examples. Discuss the user’s interfaces and briefly...
System security; discuss software and hard system securities. Give examples. Discuss the user’s interfaces and briefly give examples of its origin (Hint:MS DOS) OS.
Software Design Software designers take on a number of important roles including: software architect, enterprise architect,...
Software Design Software designers take on a number of important roles including: software architect, enterprise architect, component designer, user interface designer, and system engineer. Which of these roles is most important to the success or failure of a project and why? Justify your answer.
ì have to do an automated holiday scheduling system. with some constraints, such as holiday entitlement,...
ì have to do an automated holiday scheduling system. with some constraints, such as holiday entitlement, minimum number of staff levels in particular areas and balancing peak times. Any idea which algorithm should I use? Is Java with GA a good idea?
ADVERTISEMENT
Need Online Homework Help?

Get Answers For Free
Most questions answered within 1 hours.

Ask a Question
ADVERTISEMENT