# Summary and study material - SEPM Exam

### Lecture 1

#### Define software engineering, explain the engineering view on SE and what are the relevant constrains.
So a formal definiton of what SE is about the *process* to create software, using different theories, methods and tools. A common engineering view on SE is that is it seen as some type of combination between artistry and engineering. Three comon constraints of SE is time, money and organization. All of these are interconnected and could affect each other.
- Time constraint, could be caused by tight deadlines, time in which a certain software is relevant and such. How fast you can do it.
- Money constraint, by having sufficient amount of money you might not be able to buy the needed components, buy more resources, expand the development team or company and thus constraining the process of software engineering. How much money you can spend on it.
- Organization, what type of organization are you going to use and how that will affect the process.

#### Define the concept of process-based quality. Explain the advantages and disadvantages.
We measure the quality of the product instead of the quality of the process, because we don't know how to do the second.
As engineers our goal is to standarize good processes so we can be more efficient the next time we have to do the same task.
- Comments from Davide after the Self Evaluation 1:
- "Process quality refers to the degree to which an acceptable process, including measurements and criteria for quality, has been implemented and adhered to in order to produce the artifacts."
- "This is an important process because has an assumption - that good quality products can only be achieved following good quality processes - that sometimes might not be true."

#### List the 4 metrics used to measure the quality of a product, explain how we can actually measure them using a process.
- Acceptance
- Usable, learnable, compatible
- Dependable
- Safe, reliable, secure
- Efficient
- Response time, memory use
- Maintainable
- Documented, structured

We care a lot about the process, and many of these qualities actually translate into the quality of the process. A process is good if its something that people can follow, it is manageable in terms of making it visible and robust to problems, and the process should delivers, meaning that is is efficient and acceptable.

#### Identify the differences between plan driven and incremental processes.
- Plan driven process
- "Process acitivities planned in advance"
- "Progress measured against plan"
- Incremtal process
- "Manage changing" (understanding of customer requirements and change the plan accodring to these requirements)

The incremental process is more flexible and refactoring is inexpensive whilst it is expensive when doing plan driven processes. Although, plan driven is better for larger teams.


#### Describe, sketch a working diagram and explain both, when and how, the 4 main software process activities are done on the following processes. Explain the advantages and disadvantages of each one:
- Waterfall model
- "This takes the fundamental process activities of specification, development, validation, and evolution and represents them as separate process phases such as requirements specification, software design, implementation, and testing."
- Advantage:
- Precense of a clear structure
- Strict timeline
- Disadvantage:
- Since you aren't going back to previous activities until you have reached the final actitivity of "operation and maintenance", you might have to change large and crucial parts of the product that can cost a lot of time and money.
- Delayed testing


- V-Model
- Advantage
- Simple to use
- Can help to save a lot of time compared to the general process of implementation
- Works well for small projects where requirements are easily understood
- Testing activities like planning, test designing happens well before coding. This saves a lot of time. Hence higher chance of success over the waterfall model. MEANING: When you are on the left side of the V in the model, you can actually jump to the right side and start planning the tests and such, in order to prepare them before you're starting to code.
- Disadvantage
- Very rigid and least flexible
- Software is developed during the implementation phase, so no early prototypes of the software are produced
- If any changes happen in midway, then the test documents along with requirement documents has to be updated



- Incremental development
- "This approach interleaves the activities of specification, development, and validation. The system is developed as a series of versions(increments), with each version adding functionality to the previous version."
- Advantage
- Compared to the waterfall model:
- Cost of requirement changes is reduced
- Easier to get customer feedback on the devlopment work that has been done
- Early delivery and deployment of useful software to the customer is possible even if all the functionality has not been included.
- Disadvantage
- From a management perspective:
- The process is not visible. Managers need regular deliverables to measure progress. If systems are developed quickly, it is not cost effective to produce documents that reflect every version of the system.
- System structure tends to degrade as new increments are added. Regular change leads to messy code as new functionality is added in whatever way is possible. It becomes increasingly difficult and costly to add new features to a system. To reduce structural degradation and general code messiness, agile methods suggest that you should regularly refactor (improve and restructure) the software.


- Reuse-based development
- Software engineering strategy where the development process is geared to reusing existing software.
- Advantage
- d
- Disadvantage
- d


### Lecture 2

#### Define user requirements.
Requirements are not how the software works, we want to know the what. What is the software, what is the object, what is the goal?

Then, what is the definition of user requirements? User requirements are abstract statements of the system, requirements for the customer and end-user of the system. Most important characteristics of the system.

#### Define system requirements. Compare user requirements and system requirements in terms of what they describe, how they are created and how they are used.
System requirements are a more detailed description of the functionality to be provided

User requirements are abstract and written in natural language and portrays what the user wants.

System requirements are more concrete and detailed, it is written in both natural and formal language. States what the system provides and also used a contract or product description.

#### Define functional requirements.
Functional requirements are what the system should do.

#### Define non-functional requirements. Compare functional requirements and non-functional requirements in terms of what they describe and how they are used.
Non-funcitonal requirements are constraints of the system as well as quality standard of the system.

Functional requirements: What are the FUNCTIONS of the system, how it in its entirety works, what you can do with the system. All desired functionality is covered and they should not contradict each other. Ex. the system can... calculate a mathematical equation, be change the settings, can turn the lights on.

Non-funcitonal requirements: Contraints and quality of the product. These requirements can come from internal and external sources such as the government, medical agency, ex. laws constraining the product. Usually these requirements are also measurable/testable. Ex. latency, precicsion, size.


#### Formulate functional and non-functional requirements from a brief description of a product.

Example: Twitter is a microblogging and social networking service ... on which users post and interact with messages known as "tweets".

Functional requirements:
- A user can post a "Tweet" on their profile
- A user can change their profile picture
- A user can refresh the feed of Tweets

Non-functional requirement:
- A user can only post a "Tweet" with 280 characters
- A user can change their profile picture to an image of maximum file size of 2MB
- A user can only refresh once every 2 seconds

#### Describe, sketch a working diagram of the spiral view of process, emphasising the actors responsible for each process and their main responsabilities.
Activities are organized as an iterative process around a spiral. Early in the process, most effort will be spent on understanding high-level business and non-functional requirements, and the user requirements for the system. Later in the process, in the outer rings of the spiral, more effort will be devoted to eliciting and understanding the non-functional requirements and more detailed system requirements.

This spiral model accommodates approaches to development where the requirements are developed to different levels of detail. The number of iterations around the spiral can vary so that the spiral can be exited after some or all of the user requirements have been elicited.


#### Define requirements elicitation, explain its use in the software engineering process and the role of all actors involved.
The practice of researching and discovering the requirements of a system from users, customers, and other stakeholders

Developers/engineers elicitate the requirements from the different actors involves.

#### Define requirements specification, explain its use in the software engineering process and the role of all actors involved.
A description of a software system to be developed based on natural language and models. Structured as use cases

#### Formulate a well structured user stories as a use case using the natural language and UML.
Example: Twitter

US1: As a user, I want to be able to change my profile picture, so I can represent myself
US2: As an admin, I want to be able to remove users, so I can feel more in control


#### Define requirements validation, explain its use in the software engineering process and the role of all actors involved.

The process of checking that requirements defined for development, define the system that the customer really wants

#### Define requirements verification, explain its use in the software engineering process and the role of all actors involved.

The process of ensuring the requirement meets the rules and characteristics defined for writing a good requirement

#### List the desired characteristics of system requirements. Explain how we can actually measure them.


#### Compare user stories and tasks in agile methodologies.

### Lecture 4

#### Define software design.

Composition of a single program, cares of one single program
Decomposition into layers → into modules and I can see how these interact with each other
Interaction patterns

Def: "Software design is the process by which an agent creates a specification of a software artifact intended to accomplish goals, using a set of primitive components and subject to constraints"

#### Define system design. Compare software design and system design in terms of how the programs are composed.

Multiple programs, that has to work with each other. We care where they are located physically, for example, where are the servers, how the database information is going to distributed to the server, how from any device are you going to reach this information, what happends if the network connection is cut and you cannot access the information? What is the most cheap way of building this server?

Def: "System design is the process of defining the elements of a system such as the architecture, modules and components, the different interfaces of those components and the data that goes through that system. It is meant to satisfy specific needs and requirements of a business or organization through the engineering of a coherent and well-running system"

"The designer is concerned with what happens when a user presses a button, and the architect is concerned with what happens when ten thousand users press a button."

#### Describe the model for design process. Explain the function of the following activities in the context of software specification: design inputs, design activities, design outputs.

##### Design inputs:
A series of requirements and specification, with a description of data, what information we want to store and where we want to store it and what the data represents. Many times we have the platform information, what devices are we use, OS, constraints from the hardware perspective

##### Design activities:

Three main categories, architechtural design, interface design (how the user is going to interact with architechtural design) and component design (how this interface is going to split our design), architechtural design and component design will go into the database design.

##### Design outputs

Result of design activities. Four different outputs, system architecture, database specification, interface specification and component specification, most important is the system architecture.

#### Describe, sketch a working diagram and classify the architectural patterns as physical vs. logical. Compare the advantages and disadvantages between systems:
Physical: Hardware, how things are located in hardware.
Logical: Software, how the software is connected.

- Client-server
- Physical
- All boxes different piece of hardware
- What not how
- Clients - upper, do something, start an operation
- If you do nothing, the server does nothing
- Servers - lower, to server, apply to the client what the client want
- Example, spotify, you want to play something by clicking it, sends a request to a server which provide you with the song.
- Internet is the middleware
- Handles requests, who gets what first for example
- Old
- Problems: Large traffic is limited due to hardware network. Bottleneck
- Easy to extend
- Secure - where the data is located, only one place, all effort of security is focused there


- Master-slave
- Physical
- Tries to solve the problem of bottlenecking as described in the Client-server
- Splitting the architecture
- Three types of components
- Masters
- Slaves
- Clients
- Master
- A piece of hardware that talks with other server
- Coordinate the connection
- Slaves
- Connected with the clients
- Ex. Sensors devices
- Clients
- Ex. Traffic lights, Google Home
- Enables scaling
- If the slave failes, for some reason, the other slaves are still working
- You separate the tasks and reduce the risk of failure
- The master is more complex, could be a huge bottleneck if the master failes
- Dedicated processes
- Great for real-time systems
- Not so extensible/secure


- Distributed component
- Physical
- Instead of having a single machine that is doing a single task
- Multiple machines doing the same task
- Replicate the same task
- Ex. instead of having a servers that controlles traffic lights and one server which controlls traffic flow, you have a server which can do both.
- Client
- Talks with a middleware, which communicates with these components
- Large systems like Facebook uses this
- Allows system designers to delay decision on when/how services are provided
- Flexible/scalable/extensible/auto-reconfiguration
- Complex


- Layered model
- Logical
- Each box is a component
- Provides a service to up
- Gets a service from down
- Generic application
- Database
- Provides data to application processing
- Application processing
- Process the data
- Sent it do data handling
- Data handling
- Summarize the data
- Send to presentation
- Presentation
- Present it to the user
- If a component need something, it has to ask the layer below
- If you "don't like" a specific layer, you can easily swap it out and change a component
- Simple
- Flexible
- Con: Everytime you need something you have to ask the presentation layer and then it has to go through all other layers


- Model-view-controller
- Logical
- Improves layer model
- Three different logical components
- View
- How you are interacting with the application
- Show some model
- Render graph
- Asks model for data
- Model
- Provides data to the view
- Controller
- Sometimes you have data as the view component then you call the controller to change how the view components shows the data.
- Data can change independently of its representation
- Allows presenting same data in multiple ways
- Might involve extra coding
- Requrires to adapt the logical architecture


#### Describe the N-tier architectural model. Explain the differences between a thin and fat client version.
N-tier architecture is also called multi-tier architecture because the software is engineered to have the processing, data management, and presentation functions physically and logically separated. That means that these different functions are hosted on several machines or clusters, ensuring that services are provided without resources being shared and, as such, these services are delivered at top capacity.

N hardware pieces connected together

Thin vs Fat, how much work is put on the client
- Thin client (ex. Facebook on the phone, everything happens on the server):
- Good
- Simple client (browser, mobile app)
- Security
- Bad
- Server load/traffic load
- Fat client (ex. ATM that gives you cash, the ATM machine is doing a lot of work, not only servers):
- Good
- Less server load
- Bad
- Need to install client
- Bad security


### Lecture 6

#### Define code reviews. Explain why they are an important inspection tool.

Somebody other than the author comments on the program code.

Code reviews reduces the defect rates of the code
Cheaper bug fixes
An increast in maintainability (clean code preemptively)

#### Describe and classify the following review processes based on how formal they are. Compare the advantages and disadvantages between processes:
- Pair programming
- Code review happens naturally, as the other pair member reads what is written.
- Pros:
- Everything is read by 2 people
- Cons:
- No benefit of distance
- Expensive
- Over-the-shoulder
- One programmer presents their work to a reviewer. The programmer is at the keyboard and walks the reviewer through the code.
- Pros:
- Light-weight
- Can be used selectively
- Explanations are readily available
- Cons:
- Little time for reflection
- Easy to over-explain
- Coverage not guaranteed
- Peer review
- The reviewer inspects a chunk of source code of the programmer, and comments on it.
- Pros:
- Gives time for reflection
- Can be on demand
- Highlights code documentation issues
- Cons:
- Can be seen as adversarial
- Pre-checking
- Every check-in is inspected by the owner of the module before being accepted.
- Pros:
- Everything is inspected
- Check-in message gives context
- Knowledgeble reviewer
- Frequen reviews
- Cons:
- Time consumption
- Legacy
- Tools needed
- Formal meeting
- Several reviewers and programmers sit together for a meeting to discuss previously inspected code.
- Pros:
- Many eyes on the code
- Can handle large change sets
- Observer friendly
- Cons:
- Schedule meetings is hard / expensive
- Group dynamics and ego concerns

#### Describe how the inspection process works. Explain what are different activities and who is responsible for them before, during and after the meeting. Explain the advantages and disadvantages of the process.
The inspection process starts off by planning when the meeting is happening and prepare the group for that activity. Then we have the individual preparation which only involves the reviewer. The person that has to read through all the things thats going to be discussed during the meeting. Then after that we have the actual meeting where the code is discussed, they don't fix the code druing this meeting, that happens during the next step in this process. This is when the code is improved and the errors are corrected. And the last step of the process is follow-up checks


#### Define the concept of legacy system.

#### Enumerate the two key metrics we use to decide if to scrap, keep or refactor legacy systems.

#### Describe and sketch a diagram how the two metrics are used to inform the decision of scraping, keeping or refactoring legacy systems.

### Lecture 9

#### Define cost model.

#### Explain what are the aspects that can influence the development cost of a product in the following models:
- Budget-limited model
- Plan-based model
- Algorithmic cost models

#### Define group dynamics and why they are important for project management.

An important aspect of effective teamwork entails understanding group dynamics in terms of both team situation and individual temperament. A good group dynamic leads to a more effective workflow, workload, communication and increases the effort of both the individual and the team.

#### Describe the Tuckman's stages of group development and sketch a working diagram emphasising how we can influence each stage.


#### Describe the GRIP model.


#### Assess and compare how a development team is performing using group dynamics theories.

#### Evaluate your own group's hazards, strengths, weakness and performance using group dynamics theories.

# Notes

Requirements engineering process