INF43 Final
Requirements Specification: Application Context
Describes the situation in which the software will be used. - Home, office, inside, outside, etc. Identifies all things that the system affects. - Objects, processes, other software, hardware, and people
Relationships Between Classes: Inheritance
An inherited class is called a subclass of its parent class or super class. It is a mechanism for code reuse and to allow independent extensions of the original software via public classes and interfaces.
Architectural Erosion
When a system evolves, ideally its prescriptive architecture is modified first In practice, the system - and thus its descriptive architecture - is often directly modified Architectural erosion happens when a system evolves and its prescriptive architecture is not updated. Architectural erosion happens when the "as-designed" architecture and the "as-implemented" architecture do not match.
What matters most from this software engineering perspective: User
"Everything the user sees"
For this UML class diagram, which of the following would you expect to see its corresponding code? Mark all that apply. - Class "B" has a field "a" of type "A" - Class "B" has a field "aList", which is a collection of objects of type "A" - Class "A" has a field "bList", which is a collection of objects of type "B" - Class "A" has a field "b" of type "B" .___ ...........__ |A|*----1|B| ---............--
- Class "A" has a field "b" of type "B" - Class "B" has a field "aList", which is a collection of objects of type "A"
Top Software Failure Causes: Lack of Rigor and Formality
- Lack of discipline in development processes - Lack of methodical usage of metrics
Top Software Failure Causes: Requirements issues
- Lack of user input/involvement - Incomplete requirements and specifications - Changing requirements and specifications
Ziv's Law
- Software development is unpredictable and the documented artifacts such as requirements will never be fully understood - Uncertainty is inherent and inevitable in Software Engineering processes and products!
The term "requirements specification" is used to refer to which of the following? - The process of documenting the requirements of the software product to be built - The requirements document - The process of coming to know and understand what the software product should be
- The requirements document - The process of documenting the requirements of the software product to be built
Which of the following statement is NOT CORRECT? - Software Architecture consists of components and connectors, which can be arranged into configuration - Not all design decisions should be considered as part of software architecture. - Mixing different styles in software architecture is inappropriate. Architects should always stick to one single architectural style. - Architectural erosion happens when the software is not grown as it was prescribed.
Mixing different styles in software architecture is inappropriate. Architects should always stick to one single architectural style.
What matters most from this software engineering perspective: Business
Money
Separation of Concerns: Divide and Conquer
A divide-and-conquer algorithm recursively breaks down a problem into two or more sub-problems of the same or related type, until these become simple enough to be solved directly.
Requirements Specification
A document that serves as the fundamental reference point between customer and software producer. It defines: - the "what," not the "how" - environmental requirements on the software - constraints on the software - software qualities
Use Case Diagrams
A graphical view of actors, use cases, and their interactions
Relationships Between Classes: Whole-Part Aggregation
One object contains (or is composed of) a set of other objects Aggregation relationships are transitive and asymetric
Architectural Style
A named collection of architectural design decisions that result in beneficial qualities in each resulting system.
Architectural Styles: Peer-to-peer
A peer-to-peer (P2P) architecture consists of a decentralized network of peers - nodes that are both clients and servers. P2P networks distribute the workload between peers, and all peers contribute and consume resources within the network without the need for a centralized server. Key benefits - Efficient - Robust
Requirements Specification: Environmental Requirements
Platforms - Hardware such as operating systems, types of machines, memory size, hard disk space - Software:Is it a Web app? Mobile app? Desktop app? Is it open source? Linux? Apache? PHP/MySQL? Is it enterprise software? .Net? Enterprise Java, J2EE? Programming language(s) Standards
Architectural erosion happens when:
The "as-designed" architecture and the "as-implemented" architecture do not match
Architectural Styles: Client-server
The client-server architecture refers to a system that hosts, delivers, and manages most of the resources and services that the client requests. In this model, all requests and services are delivered over a network, and it is also referred to as the networking computing model or client server network. Key benefits - Sharing data and services over a wide range of clients - Centralized control over access, functionality, data
Flows
A sequence of steps describing an interaction between a "user" and a "system" A use case describes a set of flows that together accomplish a specific user "goal"
Architectural Styles: Model-view-controller
A software architectural pattern commonly used for developing user interfaces that divide the related program logic into three interconnected elements. Key benefits: - Modularity - Anticipation of change
Use Case
A textual description of a set of actions defining interactions between an actor and the system to achieve a goal Includes: - Basic functionality/goal - Any precondition - Flow of events - Any postcondition - Any error condition and/or alternative flow A use case describes a set of flows that together accomplish a specific user "goal" A use case is a dialogue between actors and the system Use cases go hand-in-hand with requirements
Exception Flow
A use case exception flow is an unintended path through the system usually as a result of missing information or system availability problems. Exception flows represent an undesirable path to the user. However, even though the exception flow has occurred the system will ideally react in a way that recovers the flow and provide some useful information to the user.
Relationships Between Classes: Whole-Part Composition
A variant of aggregation which adds the property of existence dependency
Information Hiding
Hide design decisions that are most likely to change, thereby protecting other parts of the program from change if the design decision is changed "Showing only those details to the outside world which are necessary for the outside world and hiding all other details from the outside world."
High Cohesion/ LowCoupling
High Cohesion: Grouping related functionality - Cohesion is relationships between modules Low Coupling: Ungrouping unrelated functionality / reducing interdependency - Coupling is relationships between packages Effects: - Changes don't propagate - Reuse is facilitated
Design Principles
High cohesion/low coupling Information hiding
Requirements Specification: Functional Requirements
Identifies all concepts, functions, features, and information that the system provides to its users Provides an abstraction for each of those, characterizing the properties and functions that are relevant to the user - What is the system supposed to do? - What information does the system need? - What is supposed to happen when something goes wrong?
What is relational database design?
Designing tables where data is stored and relationships between them
Requirements Specification: Assumptions
Factors that are believed to be true during the life cycle of the project. If changed, they may affect the project outcomes negatively Examples - end-user characteristics - known technology infrastructure - resource availability - funding availability
In the requirements document, if you were to describe the list of desired features of the software and how they should work, into which section would they most likely go?
Functional Requirements
Which of the following statement is NOT correct? - In a requirement document, executive summary shouldn't be too long and should be concise and to-the-point. - The majority of software developers are employed to produce software for their own company's use. - In a use-case diagram, the stick figures are drawn to always represent humans that interact with the system. - Use cases are bad for describing the quality of software.
In a use-case diagram, the stick figures are drawn to always represent humans that interact with the system.
Cohesion
Many tight dependencies or associations within a component, and high levels of this is desirable for a good design
In the Layered architectural style: - The upper layers are the most reusable. - Any component can communicate with any other component in the architecture. - Components are organized around one centralized server. - None of these
None of these
Architectural Styles: Pipe-and-filter
Pipe and Filter is another architectural pattern, which has independent entities called filters (components) which perform transformations on data and process the input they receive, and pipes, which serve as connectors for the stream of data being transformed, each connected to the next component in the pipeline. Key benefits - Modularity - Reuse - Anticipation of Change
Architectural Styles: Publish-subscribe
Publish/subscribe messaging, or pub/sub messaging, is a form of asynchronous service-to-service communication used in serverless and microservices architectures. In a pub/sub model, any message published to a topic is immediately received by all of the subscribers to the topic. Key benefits - Efficiency - Scalability
Which one of the following statements about requirements is true? - Requirements issues are at the root of many software failures. - Requirements describe how the software should work, without saying what it should do. - The requirements phase is the mostly costly phase in the software life cycle, in terms of dollars spent. - Requirements errors generally cause only minor problems in the resulting system. These problems are simple and cheap to fix. - Requirements analysis/engineering should only be done once the architecture of the system has been designed.
Requirements issues are at the root of many software failures.
No Silver Bullet Summary
Software engineering is hard because of the essential difficulties of software - Complexity - Conformity - Changeability - Invisibility
Requirements analysis could be performed in a number of ways. Which of the following is NOT a requirements analysis technique? - Software quality assurance techniques, such as testing- Observing the customer - Researching other past solutions - Prototyping solutions and getting feedback from the customer - Interviewing the customer - Gathering and utilizing data analytics
Software quality assurance techniques, such as testing
A descriptive architecture is necessarily... - A disciplined set of dependencies among components that adheres to the envisioned architecture - The result of architectural erosion - The architecture that can be can always be inferred from the implementation - The architecture that the architect decides for the project to guide how the software will be designed and implemented
The architecture that can always be inferred from the implementation
A prescriptive architecture is...
The architecture that the architect decides for the project to guide how the software will be designed and implemented
Which one of the following statements about requirements is false? - What the customer wants is sometimes not the same as what the customer needs. - The requirements phase is the mostly costly phase in the software life cycle, in terms of dollars spent. - If you get the requirements right, it will help avoid many costly fixes later on in the software life cycle. - Requirements issues are at the root of many software failures. - Requirements describe what the software should do, without saying how it should do it.
The requirements phase is the mostly costly phase in the software life cycle, in terms of dollars spent.
Functional Decomposition
Think of a system as a function and break it down into smaller, simpler functions. Then, rebuild these small functions to build system.
What is the purpose of a UML class diagram?
To create a detailed, object-oriented design of the code
A detailed, object-oriented design is usually depicted as a(n):
UML class diagram
Which of the following is not true about an architect? - Usually is a key decision maker on the direction of how to make difficult implementation choices - Usually has broad training (in the domain and in software development) - Often leads the technical development team - No answer text provided. - Often serves as an interface between key business stakeholder and the technical team - Usually is an entry-level position
Usually is an entry-level position
Requirements
What the software should do (without saying how it should do it) Requirements address what a customer needs, not what a customer wants
Scope of a Use Case
What, not how (in other words, it expresses how a user accomplishes a goal using the system, rather than how the system performs) Use audience-friendly terminology Include: - How the use case starts and ends - The interactions (in sequence) between use case and actors - What data is needed by/exchanged during the use case - Basic flow - Alternative/exception flows (if applicable)
Which one of the following statements is true about software architecture? - When software evolves, architecture is a valuable tool in facilitating that evolution. - Software architecture dictates the process a team uses to develop use cases for a system. - Software architecture defines the detailed, low-level structure of an implementation. - All of these statements are true. - Software architecture consists of all the design decisions about a software system.
When software evolves, architecture is a valuable tool in facilitating that evolution.
Imagine you are creating a UML class diagram of an e-commerce system (such as amazon) that sells items. Which of the following is most likely to be an operation of an Item class? - price - addToCart - fileSize - description - logIn
addToCart
In software architecture what is the definition of a configuration
all elements of the architecture laid out in a specific way that describes the overall architecture (or architectural style)
Prescriptive Architecture
as-designed/as-intended architecture
Descriptive Architecture
as-implemented/as-realized architecture
In software architecture what is the definition of a component
elements that comprise functionality and/or computation
In software architecture what is the definition of a connector
elements that handle interaction between the different parts of the architecture
Imagine you are creating a UML class diagram of an e-commerce system, such as amazon. Which of the following is most likely to be an attribute of a Customer class? - fileSize - writeReview - name - logOut - price
name
Which one of the following is true about software architectural styles? - A software architectural style provides us with a named set of components, connectors, and configurations. - The client-server style is applicable to any given problem/context." - Using a software architectural style broadens the architectural design decisions we can make. - A software architectural style rarely offers benefits to the resulting system. - Using a software architectural style usually makes it harder to evolve the resulting system
A software architectural style provides us with a named set of components, connectors, and configurations.
Elements of Software Architecture
A software architecture consists of (elements of software architecture): - Components - Connectors - Components and connectors are arranged into configurations
Separation of Concerns: Modularity
A software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.
Software Architecture
A software system's architecture is the set of principal design decisions about the system Software architecture is the blueprint for a software system's construction and evolution "The set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both." [Clements, Bass, Kazman] "How your whole system (in the widest possible sense) will be decomposed into processes or services; how data are stored, communicated, and processed; and how all parts fit together to deliver the required functionality, reliability, capacity, scalability, maintainability, and portability." [Spinellis] "The highest-level breakdown of a system into its parts; the decisions that are hard to change." [Fowler] "The clear definition of multiple high-level components that, when working together, form your system and solve your problem." [Natarén] Elements of Software Architecture: A software architecture consists of (elements of software architecture): - Components - Connectors - Components and connectors are arranged into configurations
For this problem, consider the publish-subscribe architectural style. a) Describe the job of each component in a publish-subscribe architecture b) Describe a real-world system designed in the publish-subscribe style style (not the stock-market-ticker example that was used in class), and describe the job of each component and connector in this system specifically.
A) The components in a publish-subscribe architecture are publishers and subscribers. Publishers release content such as articles/news to their website and subscribers receive this information from their website in return for their watchtime (or "clicks") and possible payment from subscriptions. B) Real-world systems designed in the publish-subscribe style are a lot of news websites. They have subscriber-only articles that require viewers to subscribe to them to see. The subscribers pay a monthly/yearly fee in order to receive these subscriber-only articles from the publisher's website. The connectors in this case is the subscription management systems on their websites. The publishers publish their articles on their website. Viewers then log into this website and get to read these published articles as long as their account has a subscription. The connectors between the publishers and subscribers, then, is the subscription management systems on the website. A) the first level of components is publishers that are producing content then the connector sorts what information goes where and then gives information to the subscribers accordingly. B) YouTube is an example of the publish-subscribe style. The content creators or "YouTubers" are that first level of components. The information then gets sorted through the subscription manager and gives the content to their subscribers accordingly
For this question, you will be considering two example software systems and software qualities ("ilities"/non-functional requirements). Consider two software products: TikTok (social media video sharing service) Tesla Autopilot (advanced driver-assistance software system) For this question, answer all four parts: A1. Name a quality (non-functional requirement quality) that is more important for TikTok than Autopilot. A2. Describe why you think that that quality is more important for TikTok. B1. Name a quality (non-functional requirement quality) that is more important for Autopilot than TikTok. B2. Describe why you think that that quality is more important for Autopilot.
A1. A non-functional requirement quality that's more important to TikTok than Autopilot is adjectives such as "eyecatching" and "pretty" when describing it's interface. A2. TikTok is trying to keep their users hooked to their social media platform and having an eyecatching and pretty quality is important for that so the users don't lose interest. Autopilot, on the other hand, doesn't need to keep a userbase engaged as it's not a entertainment/social media platform. B1. A non-functional requirement quality that's more important to Autopilot than TikTok is definitely reliability and easy usage. B2. Since Autopilot is more of a tool than TikTok is, qualities such as reliability and easy usage is far more important as users approach AutoPilot as a tool and it's important they aren't frustrated due to the tool's complicated features and feel satisfied relying on the driver assistance. TikTok is a social media platform, so there's not as much importance placed on reliability/easy usage as there is on engaging qualities such as being eyecatching/pretty. A1) Portability A2) You want to be able to use Tiktok on multiple hardwares and devices while Tesla only needs to work one their cars. B1) Reliability B2) You need the autopilot to be reliable because people's lives are at risk. Where as if TikTok doesn't work or if there's an issue no one will get hurt.
A function call presents a simple interface and hides the logic that will be performed. This is an example of...
Abstraction
Alternative Flow
An alternate flow describes a use case scenario other than the basic flow that results in a user completing his or her goal. It is often considered to be an optional flow and implies that the user has chosen to take an alternative path through the system.
Requirements Specification: Future Changes
Any project faces changes over time. - It is important to identify those changes up-front so you and the customer are aware of them Structure the requirements document in such a way that it easily absorbs changes - Define concepts once - Partition separate concerns - Avoid redundancy
In which section of a requirements document are you most likely to find the following statements: "The software shall run on iPads in the lobby of the library. The software shall also take input from scanners attached to the iPads, with which a patron can use to scan their cards and items. The software shall also interact with the county-wide library database to report checkouts and checkins."
Application Context
Over Optimism Disease/"Hubble Psychology"
Belief that as long as funding keeps coming, the project will eventually be successfully finished and all setbacks will be forgotten.
Which one of the following requirements analysis techniques does Netflix use the most?
Data analysis and business metrics
What is functional decomposition?
Decomposing a task, function, module, or system into smaller sub-tasks, sub-functions, or sub-modules
Which one of the following statements most naturally follows from Ziv's Law? - Requirements documents are not amenable for specifying user interfaces, data formats, business rules, and non-functional requirements. - Modern requirements analysis techniques help us create requirements documents that are high quality and rarely need to change after they are written. - Despite our best efforts, we must always assume that requirements will change and understanding will grow, resulting in changes to the requirements document. - A requirements document is the best way to represent requirements because its format makes it easy to understand for non-technical audiences. - Functional requirements should be written at a level of abstraction that is relevant to the user, and that shows what kind of data is being passed between user and system.
Despite our best efforts, we must always assume that requirements will change and understanding will grow, resulting in changes to the requirements document.
Relationships Between Classes: Association
Documents the communication that takes place between the use case and the actors that use the use case
Object-Oriented Design/Unified Modeling Language (UML)
Each module turns into a class that has a name, attributes, and functions.
Requirements Specification: Software Qualities
Examples of Software Qualities: - Correctness - Reliability - Efficiency - Usability - Maintainability - Portability - Reusability - Interoperability - Robustness - Security - Scalability
UML (Unified Modeling Language)
Industry standard for softwaredesign/modeling Different types of UML diagrams are used to represent different aspects (structure, behavior, interactions) of a system - Class diagrams - Activity diagrams - Sequence diagrams - Use case diagrams - etc.
What matters most from this software engineering perspective: Engineering
Internal quality of the software
Coupling
Many tight dependencies or associations across multiple components, and high levels of this is undesirable for a good design
What are the three essential ingredients of software engineering?
People, Processes, and Tools.
According to the IEEE Spectrum software failure reading, what is another name for "Hubble Psychology?"
Over optimism disease
Of the three essential ingredients of software engineering, which is the most important?
People
Separation of Concerns: Abstraction
Removes irrelevant info and highlights relevant info. Every design notation supports a certain kind of abstraction. Software engineering is all about describing, constructing, and elaborating abstractions/models.
Actors
Represent external entities that interact with the system Actors include: - Humans - Hardware - Another software system A use case is initiated by an actor (primary actor) to invoke a certain functionality in the system A use case is a dialogue between actors and the system
Requirements vs Design
Requirements - what Design - how
Requirements Engineering/Requirements Phase
Requirements analysis - Activity of discovering/observing/gathering customer's needs - Requirements analysis is learning what the system should do (without worrying yet about how it should do it) Requirements specification - Activity of describing/documenting customer's needs - Can also refer to the requirements document
Requirements Specification: Potential Risks
Risks: "future uncertain events with a probability of occurrence and a potential for loss" Any project faces risks: - new methodology - requirements new to the group - special skills and resource shortage - aggressive schedule - tight funding - security - ethical It is important to identify those risks up-front so you and the customer are aware of them
Requirements Specification: Executive Summary
Short, succinct, concise, to-the-point, description of the product. No more than one page. Identifies: - main goals - key features - key risks/obstacles
In a specification, which section would you describe that that software should be built to be secure and beautiful?
Software Qualities
Architectural Styles: Layered
The layered architecture style is one of the most common architectural styles. The idea behind Layered Architecture is that modules or components with similar functionalities are organized into horizontal layers. As a result, each layer performs a specific role within the application. Key benefits - Modularity - Abstraction - Anticipation of Change - Reuse
The "requirements" phase of the software lifecycle can be broken down into two sub-phases: "analysis" and "specification". What is requirements analysis?
The process of coming to know and understand what the software product should be
Briefly describe the software-engineering principle of "anticipation of change" and give an example of a software-engineering task or concept that demonstrates this principle.
The software engineering principle of "anticipation of change" is to acknowledge that change is going to happen. Developers design their software with this in mind by making their software easily changeable in order to adjust and adapt with the times. Developers also have version control to easily see older versions of their software. These strategies prepare for the inevitable changes in the software world due to changes in technology and the software market. Anticipation of change means being aware that software is constantly changing and people always expect the latest technology. For example, Apple releases new iPhones, and people wait for and buy the latest model.
Briefly describe the software-engineering principle of "incrementality" and give an example of a software-engineering task or concept that demonstrates this principle.
The software engineering principle of "incrementality" is to simplify the software development process. Developers do this by breaking up complex problems into simpler ones by separating code in to smaller chunks, that, when combined, solve a larger and more complex problem. This is why it's called "incrementing" (aka, incrementally developing a software in steps or small chunks). Prototypes are quickly produced under the principle of "incrementality" in order to quickly receive feedback. "Incrementality" focuses on functionality first before focusing on performance. An example of this principle is making sure your functions each explicitly do one simple thing: this forces you to break down your problems into simple bitesized chunks, simplifying the entire development process. Incrementality means slowly adding features as time goes on. For example, releasing a software and then adding new features and bug fixes through updates. Because you can't wait for a software to be perfect to release it, otherwise we'll never release it.
Briefly describe the software-engineering principle of "rigor and formality" and give an example of a software-engineering task or concept that demonstrates this principle.
The software engineering principle of rigor and formality is the principle of designing and producing a well made software that avoids as many avoidable problems/hiccups in the design process. Rigor is to set up rules and regulations that are used throughout the software design process. Formality is rigor at the highest level, which is when software can be verified via mathematical laws. An example of a software-engineering task that demonstrates this principle is exhaustively commenting and documenting your code and producing unittests. Rigor and formality are like the coding standard. You do not technically have to use it, but it ensures everyone's on the same page. For example, commenting on code so you know what's going on.
Briefly describe the software-engineering principle of "generality" and give an example of a software-engineering task or concept that demonstrates this principle.
The software-engineering principle of "generality" is to determine the "general" problem your software is trying to solve and to approach the software development process with this in mind. During the development of your software, you should be considering the limitations and restrictions your software may have when trying to solve your "general" problem. Are there any specific situations where your software is limited? That should be changed/fixed. A great example of failing to follow this principle is the various software that ran into problems when the year 2000 came around. Developers making software decades before the year 2000 didn't think about the unnatural/edge based cases like the year 2000 so it failed to deal with displaying the proper time when the year 2000 came around. Generality means making solutions usable in different ways, which means, making code that can be used for many things as opposed to one problem. For example making code that not only applies to one software but can be used for many different softwares.
Mr. Brown wants to create a web application that can assist people buying tickets for a cruise ship. Which of the following is the POOREST example of the requirement? - The web's backend should use the most popular programming language, Python, so that it could be easily maintained since more people know how to use it. - The web's page should provide some space for online advertising so that the advertising place could be sold to other commercial companies. - The web should support people with reading disabilities so that they could purchase the tickets smoothly. - Customers can not only purchase tickets but also join the waiting list if the tickets are temporarily sold out.
The web's backend should use the most popular programming language, Python, so that it could be easily maintained since more people know how to use it.
Requirements should define:
The what, not the how
An abstraction is formed by reducing the information content to only present information that is relevant to the task at hand, and hide information that is irrelevant to the task at hand. For example, a software requirements document presents the requirements of the software, but "abstracts away" (hides) the architecture, source code, etc. Describe at least two types of information that are hidden or "abstracted away" in a UML class diagram.
UML class diagrams show the attributes, operations, and relationships of classes in a program. These diagrams do not show the code itself (and they don't even show which programming language its written in, if its written at all yet), instead only showing the intended functionality of each class and how they relate to one another. These diagrams also do not show the overall intended use of the entire program, having only shown what each class within it does and how they're related with one another. These diagrams also do not show when any objects of these classes are created and why, which relates back to the previous two abstractions: UML class diagrams do not show how the whole program works and does not show any code, and as consequence of this, it doesn't show how any objects of these classes are created initially either. - It abstracts away the actual code of the software - It also abstracts dependencies
Relational Database Design
Use tables to store data and illustrate relationships between them. Most common type of database.
UML (Unified Modeling Language) Class Diagrams
Used in decomposing a system into modules known as classes Typically used to: - model domain concepts - create a detailed, object-oriented design of the code
If you go into a career in software engineering in the U.S., which one of the following situations is most likely outcome for you (or any random person)? - Working for a company who contracts out their services to build software for other companies - Writing software whose source code is released for free on the Internet with a team of geographically distributed individuals, on an unpaid, volunteer basis - Developing the next great virus that will steal millions of peoples' personal information| - These are all equally likely - Working in the IT department of a company, writing software for "customers" who are also part of that same company
Working in the IT department of a company, writing software for "customers" who are also part of that same company
Based on his "No Silver Bullet" essay, which one of the following pieces of advice would Fred Brooks be least likely to give? - You should always build functionality yourself from scratch rather than reuse existing software that provides the functionality you need. - We should not expect to get orders of magnitude improvement in software engineering just by building new languages and tools - It is vital to invest in growing great software designers. - It is impossible to accurately capture a customer's needs without prototyping.- It is best to build software in small, iterative chunks.
You should always build functionality yourself from scratch rather than reuse existing software that provides the functionality you need.