A brief summary of Software Engineering best practices, terminology, and general reference.
software engineering (.n)
The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches. That is the application of engineering to software.
Software Engineer vs Programmer
Imagine a person, who is good at building a wall may not be good at building a house. In a similar way, a person who can write programs does not have the knowledge to develop and implement the software in a well-defined systematic approach. Hence, there is a need for programmers to adhere to software engineering concepts such as requirements gathering, planning, development, testing, and documentation.
Software Project Manager
Project Manager is responsible for driving the software project in a systematic approach. Some of the key roles & responsibilities of a software project manager include project planning, tracking the progress of the project, risk management, resource management, execution of development activities, delivering the project under cost, time and quality constraints.
Functional and Non-Functional Requirements
Functional requirements are utilized to specify the functional features as per the business requirements. For Example, adding a payment option to buy content from a website. Non- functional requirements provide insights into security, performance, user interface, interoperability costs etc.
Modularization
Modularization divides the software system tasks in multiple modules. These modules are independent to other modules and tasks invoked in each module are executed independently.
Project Concurrency
Concurrency is a process of executing multiple events or tasks simultaneously. Concurrency can be achieved with the help of modules, events, and tasks associated with the software project delivery
The Code To Live By
- KISS (Keep it Simple Stupid)
- YAGNI (You Aren’t Gonna Need It)
- DRY (Don’t Repeat Yourself)
Software Development Process
- Planning
- Requirements Analysis
- Design Specicfication
- Development & Implementation
- Testing
- Maintenance
Software Development Life Cycle Models
- Waterfall Model
- Iterative Model
- Spiral Model
- Agile
- XP
Big-O Cheat Sheet
Data Structures
| Structure | Access | Search | Space |
|---|---|---|---|
| Array | O(1) | O(n) | O(n) |
| Linked List* | O(n) | O(n) | O(n) |
| Stack (LIFO) | O(n) | O(n) | O(n) |
| Queue** (FIFO) | O(n) | O(n) | O(n) |
| Binary Tree | O(n) | O(n) | O(n) |
| Binary Search Tree | O(n) | O(n) | O(n) |
| Binary Heap | O(n) | O(n) | O(n) |
| AVL Tree | O(n) | O(log n) | O(n) |
| Hash Table*** | O(n) | O(n) | O(n) |
| Graph | O(n) | O(n) | O(n) |
* Doubly Linked List, Circular, Linked List
** Priority Queue, Double Ended Queue, Circular Queue
*** Hash Table has an average search of O(1)
Sorting Algorithms
| Algorithm | Time | Space |
|---|---|---|
| Quicksort | O(n^2) | O(log(n)) |
| Mergesort | O(n log(n)) | O(n) |
| Heapsort | O(n log(n)) | O(1) |
| Bubble Sort | O(n^2) | O(1) |
| Insertion Sort | O(n^2) | O(1) |
| Selection Sort | O(n^2) | O(1) |
| Tree Sort | O(n^2) | O(n) |
| Bucket Sort | O(n^2) | O(n) |
| Radix Sort | O(nk) | O(n+k) |
Search Algorithms
| Algorithm | Time | Space |
|---|---|---|
| Linear Search | O(n) | O(1) |
| Binary Search | O(n log(n)) | O(1) |
| DFS | O(V+E) | O(V) |
| BFS | O(V+E) | O(V) |
| Best First Search | ||
| A* | O(E) | O(V) |
V = Vertex E = Edges
Design Patterns
- Abstract Factory
- Creates an instance of several families of classes
- Builder
- Separates object construction from its representation
- Factory Method
- Creates an instance of several derived classes
- Object Pool
- Avoid expensive acquisition and release of resources by recycling objects that are no longer in use
- Prototype
- A fully initialized instance to be copied or cloned
- Singleton
- A class of which only a single instance can exist
- Adapter
- Match interfaces of different classes
- Bridge
- Separates an object’s interface from its implementation
- Composite
- A tree structure of simple and composite objects
- Decorator
- Add responsibilities to objects dynamically
- Facade
- A single class that represents an entire subsystem
- Flyweight
- A fine-grained instance used for efficient sharing
- Private Class Data
- Restricts accessor/mutator access
- Proxy
- An object representing another object
- Chain of responsibility
- A way of passing a request between a chain of objects
- Command
- Encapsulate a command request as an object
- Interpreter
- A way to include language elements in a program
- Iterator
- Sequentially access the elements of a collection
- Mediator
- Defines simplified communication between classes
- Memento
- Capture and restore an object’s internal state
- Null Object
- Designed to act as a default value of an object
- Observer
- A way of notifying change to a number of classes
- State
- Alter an object’s behavior when its state changes
- Strategy
- Encapsulates an algorithm inside a class
- Template method
- Defer the exact steps of an algorithm to a subclass
- Visitor
- Defines a new operation to a class without change
Anti Patterns
Software Development AntiPatterns
- The Blob
- Procedural-style design leads to one object with a lion’s share of the responsibilities, while most other objects only hold data or execute simple processes. The solution includes refactoring the design to distribute responsibilities more uniformly and isolating the effect of changes.
- Continuous Obsolescence
- Technology is changing so rapidly that developers often have trouble keeping up with current versions of software and finding combinations of product releases that work together. Given that every commercial product line evolves through new releases, the situation is becoming more difficult for developers to cope with. Finding compatible releases of products that successfully interoperate is even harder.
- Lava Flow
- Dead code and forgotten design information is frozen in an ever-changing design. This is analogous to a Lava Flow with hardening globules of rocky material. The refactored solution includes a configuration management process that eliminates dead code and evolves or refactors design toward increasing quality.
- Ambiguous Viewpoint
- Object-oriented analysis and design (OOA&D) models are often presented without clarifying the viewpoint represented by the model. By default, OOA&D models denote an implementation viewpoint that is potentially the least useful. Mixed viewpoints don’t allow the fundamental separation of interfaces from implementation details, which is one of the primary benefits of the object-oriented paradigm.
- Functional Decomposition
- This AntiPattern is the output of experienced, nonobject-oriented developers who design and implement an application in an object-oriented language. The resulting code resembles a structural language (Pascal, FORTRAN) in class structure. It can be incredibly complex as smart procedural developers devise very “clever” ways to replicate their time-tested methods in an object-oriented architecture.
- Poltergeists
- Poltergeists are classes with very limited roles and effective life cycles. They often start processes for other objects. The refactored solution includes a reallocation of responsibilities to longer-lived objects that eliminate the Poltergeists.
- Boat Anchor
- A Boat Anchor is a piece of software or hardware that serves no useful purpose on the current project. Often, the Boat Anchor is a costly acquisition, which makes the purchase even more ironic.
- Golden Hammer
- A Golden Hammer is a familiar technology or concept applied obsessively to many software problems. The solution involves expanding the knowledge of developers through education, training, and book study groups to expose developers to alternative technologies and approaches.
- Dead End
- A Dead End is reached by modifying a reusable component if the modified component is no longer maintained and supported by the supplier. When these modifications are made, the support burden transfers to the application system developers and maintainers. Improvements in the reusable component are not easily integrated, and support problems can be blamed upon the modification.
- Spaghetti Code
- Ad hoc software structure makes it difficult to extend and optimize code. Frequent code refactoring can improve software structure, support software maintenance, and enable iterative development.
- Input Kludge
- Software that fails straightforward behavioral tests may be an example of an input kludge, which occurs when ad hoc algorithms are employed for handling program input.
- Walking through a Minefield
- Using today’s software technology is analogous to walking through a high-tech mine field. Numerous bugs are found in released software products; in fact, experts estimate that original source code contains two to five bugs per line of code.
- Cut-and-Paste Programming
- Code reused by copying source statements leads to significant maintenance problems. Alternative forms of reuse, including black-box reuse, reduce maintenance issues by having common source code, testing, and documentation.
- Mushroom Management
- In some architecture and management circles, there is an explicit policy to keep system developers isolated from the system’s end users. Requirements are passed second-hand through intermediaries, including architects, managers, or requirements analysts.
Software Architecture AntiPatterns
Software Project Management AntiPatterns
HTTP Request Life Cycle
- Create a socket on port-80 for the connection.
- First the browser needs to translate www.google.com to an IP address if it does not already know it. If it knows it, nothing happens at this point. If it does not know it, it contacts a DNS server to resolve the name.
- Then browser will open a TCP connection (via a 3-way handshake) to the IP address of www.google.com and send a HTTP GET request over port 80 with the IP in the header. In this example it will be
GET / HTTP/1.1 - The server software will get this HTTP request. It will somehow generate a HTTP response and send that back trough the TCP connection. It will open and close a connection for each asset (HTML, IMG, JS).
- When the browser gets the response, it typically renders it on screen. The HTTP request is now done.
HTTP Request Methods GET, PUT, POST, DELETE.
Testing
- Black box testing is performed to validate the outputs along with valid inputs given. But, it does not test the implementation part of the program.
- White Box testing is performed to validate the inputs, outputs and program implementation involved in its execution.
Software Metrics
- Product Metrics
- Size and complexity of software.
- Quality and reliability of software.
- Process Metrics
- Efficiency
- Fault Detection
- Cohesion (High Cohesion: Good)
- The degree of interdependence between software modules
- Coupling (Low Coupling: Good)
- Degree to which the elements inside a module belong together
Software Maintenance
- Corrective
- Remove the errors spotted by business users.
- Adaptive
- Check the changes made in the hardware and software environment.
- Perfective
- Implement changes in existing or new user requirements
- Preventive
- Avoid any issues in future implementations.
Scalability
A system is considered scalable when it doesn’t need to be redesigned to maintain effective performance during or after a steep increase in workload. It reflects the ability of the software to grow or change with the user’s demands.
“Workload” could refer to simultaneous users, storage capacity, the maximum number of transactions handled, or anything else that pushes the system past its original capacity.
If needed, how would you go about designing scalable applications?
You design scalable projects by writing as little code as possible. You also want to reuse as much code as you can while not over or under doing your design. Then break things down into modular sections that can run on multiple or separate systems.
- Write as little code as possible (low complexity)
- Reuse as much code as possible
- Modularize and Containerize
Threading
What is the difference between a process and a thread?
The Process and Thread are the essentially associated. The process is an execution of a program whereas thread is an execution of a program driven by the environment of a process. Processes are isolated with each other whereas threads share memory or resources with each other.
What is multi- threading?
In computer architecture, multithreading is the ability of a central processing unit (CPU) (or a single core in a multi-core processor) to provide multiple threads of execution concurrently, supported by the operating system. This approach differs from multiprocessing. In a multithreaded application, the threads share the resources of a single or multiple cores, which include the computing units, the CPU caches, and the translation lookaside buffer (TLB).
REST
REST, or REpresentational State Transfer, is an architectural style for providing standards between computer systems on the web, making it easier for systems to communicate with each other. REST-compliant systems, often called RESTful systems, are characterized by how they are stateless and separate the concerns of client and server.
Statelessness: Systems that follow the REST paradigm are stateless, meaning that the server does not need to know anything about what state the client is in and vice versa.
Questions?
- What is ORM?
- Why do you think that the maintenance of software is expensive?
- Why do we need polymorphism?
- Explain software reengineering?
- Explain the difference between stack and queue?
- Define cohesion?
- How to prioritize requirements? (risk, priority and ideal hours)
- Explain a few project management tools.
- (McCabe, SOEN 384)
- Gantt Charts
- PERT Charts
- Milestone Checklists
- Define software metric?
- Difference between a process and a thread?
- The Process and Thread are the essentially associated. The process is an execution of a program whereas thread is an execution of a program driven by the environment of a process.
- Another major point which differentiates process and thread is that processes are isolated with each other whereas threads share memory or resources with each other.
- How comfortable are you in a startup environment, or do you prefer working in a more established company?
- Company fit
- Ready for startup life (plant the seeds and plow the field before you reap the harvest)
- “There’s nothing quite like building something from scratch and seeing where it goes”
- Understanding of expected workload
- Unpredictable and exciting
- What distinguishes a great software engineer from a good one? Do you feel you have those qualities?
- “A great software engineer has a healthy balance between perfectionism and pragmatism. Too often engineers want their code to be perfect, while losing sight of the overall goals of the project. A great programmer also learns not to fall in love with their own code, to keep a healthy skepticism until it’s been thoroughly tested, making sure it is the right choice for the project at hand. And yes, I believe have the qualities of a great programmer, though working on my need to be perfect is an ongoing battle.”
- Never done, need to learn when to let go.
- What’s the most important thing to look for or check when reviewing another team member’s code?
- First pass: syntax
- Second pass: functionality and readability.
- In your opinion, what are the principles of good software engineering? What are some basic principles everyone should follow?
- KISS, DRY, sometimes YAGNI
- Readable, not complicated and fancy.