Lecture 1: An Introduction to Software Development

0.0(0)
studied byStudied by 0 people
0.0(0)
full-widthCall with Kai
GameKnowt Play
New
learnLearn
examPractice Test
spaced repetitionSpaced Repetition
heart puzzleMatch
flashcardsFlashcards
Card Sorting

1/21

encourage image

There's no tags or description

Looks like no tags are added yet.

Study Analytics
Name
Mastery
Learn
Test
Matching
Spaced

No study sessions yet.

22 Terms

1
New cards

What are the two types of projects?

1. Small-scale projects

- Can be built (normally) by one person or a small team.

Requires:

–Minimal modelling.

–Simple process.

–Simple tools.

2. Large-scale Projects

- Built by a (usually large) team.

Requires:

– Extensive modelling.

– Well-defined process.

– Different types of tools.

2
New cards

What is abstraction? Why is it necessary?

Abstraction is to build possibly various models/components of a system, each one focusing on one aspect of the system.

Ex: In a building we need a foundation, we also need an electrical network, heating, A/C, plumbing, etc.

3
New cards

What is an artifact?

An artifact is any tangible by-product of the software (or system) development process.

- It's something that is created, used, or maintained to describe, design, implement, or support the system.

- The terms "diagram", and "blueprint" are sometimes used interchangeably with "artifact", but they are more restrictive: A program is an implementation artifact but it is not a diagram.

Ex:

Requirements documents (user stories, use cases)

Diagrams (UML class diagrams, sequence diagrams, ER diagrams)

Source code files

Configuration files

Database schemas

Test cases and test scripts

Build scripts or deployment descriptors

Generated documentation

4
New cards

What are the main 3 artifacts we focus on?

1. Software Requirements Specification

- Use cases

- UML domain model

2. Software Architecture Document

- UML class diagram

- UML interaction diagrams

- Architectural views

3. Code Repository

- Application code

- Testing code

- Installation and configuration code

5
New cards

Is a 100 page SAD for 1000 lines of code good?

IS a 20 page SAD for 20,000 lines of code good?

First is too long, second is too short!

6
New cards

What is a model?

- A model is normally a collection of artifacts which represents part of the system.

-> a model isn’t just one diagram or one file—it’s a set of related descriptions and files (artifacts) that together represent the system or part of it

- As a collection of artifacts, a model serves as

–> a description of one aspect of the system,

–> a tool for thought,

–> a proof of concept,

–> a form of communication with others.

- Artifacts are developed throughout the development of the project.

- The entire system is then fully captured as the collection of all (artifacts of all) models.

7
New cards

Why is abstraction and modelling necessary?

- Because engineering systems are rapidly and continuously growing in size and complexity.

- To deal with this problem, many approaches exploit abstraction and modeling

8
New cards

What are technical artifacts?

Specifically artifacts which are tangible outputs of the technical side of system or software development—things directly tied to the engineering or implementation work, rather than management or business.

- Technical artifacts are being extensively used in all engineering disciplines.

Ex: Satellite blueprint diagrams, bridge architecture diagram, etc

9
New cards

What are the different activities in a software engineering project?

- Requirements specification

- Architecture and Design

- Implementation

- Testing

- Verification

- Maintenance

10
New cards

What is requirements specification?

Includes 3 things:

- Elicitation: Gathering of requirements.

- Analysis: Build a high-level model.

- Validation: Are we building the right product? Are requirements clear, unambiguous, non-conflicting? Is it clear what the system is expected to do?

11
New cards

What is architecture and design?

Building high- and low-level models.

12
New cards

What is implementation?

Coding and debugging

13
New cards

What is testing?

Assess the quality of the system

14
New cards

What is verification?

Assess running application w.r.t. requirements specification

15
New cards

What is maintenance?

Manage changes upon deployment.

- Upon deployment, any changes to the system are collectively known as "maintenance" in order to:

-> Correct problems,

-> Prevent failures,

-> Address new requirements,

-> Support operability in a different (software or hardware) environment.

16
New cards

The importance of maintenance lies on which observations?

1. Surveys indicate that it is an activity which tends to consume a significant proportion of the resources utilized in the overall life cycle (consequently consuming a large part of the costs), and

2. Reliable changes to software tend to be time consuming. Prolonged delays during software change may result in a loss of business opportunities.

17
New cards

Why are technical artifacts important for maintenance?

- The people who will have to maintain the software system will normally be different from those who have developed it.

- Even if initial developers will be the ones to maintain the system, it is not realistic to expect that they will retain full knowledge of all design decisions and rationale.

- Lack of knowledge / technical artifacts implies that design decisions and rationale is lost.

18
New cards

What are some characteristics of large-scale projects?

- Process: Many times it is unrealistic to build the system linearly.

- Cost: Stakeholders want to know where their money goes, and what is your progress w.r.t. budget (over budget, under budget, actual cost, etc.) and what are your projections?

- Schedule: Stakeholders want to know what is your progress

w.r.t. time, (e.g. behind schedule, ahead of schedule, time-to- finish, etc.) and what are your projections.

- Size and complexity: Requires various different skills (possibly by several different teams).

- Materials and technologies.

- Risks: Monitoring and control.

19
New cards

Why is a development process needed?

- A process is a set of partially ordered steps intended to reach a goal.

- In Software Engineering, the objective is to efficiently and predictably deliver a software product that meets the needs of the stakeholders' business.

- We need a good process to do this.

- A software development process is an approach to building, deploying and maintaining software.

20
New cards

What is a linear development process?

- In a linear development process, we sequentially define the whole problem, design the entire solution, build the software, and then test the product.

- For complex and sophisticated systems, this linear approach may not be realistic.

21
New cards

What is an iterative software development process?

- Iterative development is development organized into a series of short fixed- length mini-projects called iterations.

- An iteration represents a complete development cycle: it includes its own treatment of requirements, analysis, design, implementation and testing activities.

- The outcome of each iteration is a tested, integrated and executable system (that may or may not be a release).

- The iterative lifecycle is based on the successive enlargement and refinement of a system though multiple iterations with feedback and adaptation.

- The system grows incrementally over time, iteration by iteration.

- The system may not be eligible for production deployment until after many iterations.

22
New cards

What are the big 7 things to remember in software development?

1. You are building a system normally for someone else

(stakeholder).

2. You are building a system of a size and complexity that none of us alone can build: Not the software equivalent of a dog house in your back yard, but the software equivalent of a bridge.

3. There is a difference between software system and computer program: A software system is a (possibly large) collection of artifacts that includes a code repository which contains the application code, installation and configuration code, testing code, etc.

4. Possibly several people (teams) with different specializations work on different areas / subsystems.

5. (Most of) the artifacts are part of what the stakeholders purchase.

6. You are not being paid to have fun. You are being paid to deliver a running application as well as a collection of artifacts that shows exactly (among other things that stakeholders want to see) what the product does and how it does it.

7. You are also being paid to produce a system that others should be able to study, understand and be able to maintain