An introduction to software development. Dr. C. Constantinides, P.Eng. Computer Science and Software Engineering Concordia University

Transcription

1 An introduction to software development Dr. C. Constantinides, P.Eng. Computer Science and Software Engineering Concordia University

2 What type of projects?

3 Small-scale projects Can be built (normally) by one person or a small team. Requires Minimal modelling. Simple process. Simple tools. 3

4 Large-scale projects Built by a (usually large) team. Requires Extensive modelling. Well-defined process. Different types of tools. 4

5 Abstraction and modelling Engineering systems are rapidly and continuously growing in size and complexity. To deal with this problem, many approaches exploit abstraction: Building possibly various models, each one focusing on one aspect of the system. For example, in a building we need a foundation, we also need an electrical network, heating, A/C, plumbing, etc. 5

6 Abstraction and modelling /cont. A model is normally a collection of artifacts. 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. The entire system is then fully captured as the collection of all (artifacts of all) models. 6

7 Artifacts in engineering Technical artifacts are being extensively used in all engineering disciplines.

8 Artifacts in engineering: Examples 8

9 Artifacts in engineering: Examples /cont.

10 Artifacts in engineering: Examples /cont. 10

11 Technical artifacts 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. 11

12 Activities in a software engineering project Requirements specification: 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? Architecture and Design: Build high- and low-level models. Implementation: Coding and debugging. Testing: Assess the quality of the system. Verification: Assess running application w.r.t. requirements specification. Maintenance: Manage changes upon deployment. 12

13 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-tofinish, 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. 13

14 The need for a development process 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. A software development process is an approach to building, deploying and maintaining software. 14

15 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. 15

16 Iterative software development process Iterative development is organized into a series of short fixedlength 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). 16

17 Iterative software development process /cont. 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. 17

18 The 7 things to remember 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. 18

19 The 7 things to remember 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. 19

20 Scope of this course Software Requirements Specification Use cases Domain model Software Architecture Document Class diagram Interaction diagrams Code Repository Application code Testing code Installation and configuration code 20

21 This is not fun Why can we not just code and if this is not what you want, we will refactor (and then code some more. and refactor some more ). This would be more FUN! 21

22 The 7 things to remember /cont. 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. 22

23 OK, wait a minute! We have 1000 lines of code and a 100-page SAD! Isn t this very (very) heavy? If, for a 1000 lines of code you have a 100-page SAD, you are doing it wrong! However, for a 20,000 lines of code, a 20-page SAD is very (very) lightweight. 23

24 Maintenance in software? 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. 24

25 Maintenance and the software life cycle The importance of maintenance lies on the following two 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. 25

26 Maintenance and the software life cycle /cont. Technical artifacts are 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. 26

27 Modelling: Languages and level of abstraction Through cases studies, we will demonstrate the creation of artifacts using various languages that lie at a different level of abstraction: Natural language (English, French, etc.) Modeling language (Unified Modeling Language) Programming Language (Java, Python, etc.) Discrete Mathematical notation high-level low-level 27