Software Engineering by Albert Ambroziewicz Lecture 1: Software engineering process and requirements Problems in software engineering projects Software engineering methodology Core practices of software engineering Role of requirements in the software engineering process 3 6 5 2 1 7 12 10 8 11 9 13 4 18 17 15 16 14 Użytkownik Zamawiający 1 2 3 Analityk wymagań
44
Embed
Lecture 1: Software engineering process and requirementswikidyd.iem.pw.edu.pl/attachments/SoftEng/SE1_Lecture1.pdf · Lecture 1: Software engineering process and requirements Problems
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Software Engineering by Albert Ambroziewicz
Lecture 1: Software engineering process and requirements
Problems in software engineering projects
Software engineering methodology
Core practices of software engineering
Role of requirements in the software engineering process
S OD a
Pra cownik d ydakty czny
Student
P rzejrzenie plan u zajęć z
za rz ądzanie m o cenami
D odanie spra wdzianu
Modyfikac ja spra wdzianu
Wpro wa dzenie o cen c ząstkowy ch
Z atwierd zenie o cen końcowych
Wp rowadz enie k ry te riów
o blic zania oceny k ońcowej
Sprawd zenie oc en z zajęć
U prawn io ny prac ownik dydaktyczny
Prze jrze nie p la nu z ajęć
«exten d»« extend»
S OD a
Obejrze nie listy s tu dentó w
Potwierdz enie zło żenia inde ksu
Potwierdzenie skreśle nia studenta
P rzejrze nie historii o siągnię ć
s tu denta
D ok onanie re jestracji studenta po
terminie
Obe jrzenie lis ty studentów przez
D zieka na
P otwie rdzenie wyda nia in deksu
Dokonanie zmiany rejes tra cji s tu denta
Przydzielenie s tu dentó w d o grup
Dziekan
P racownik d zie kanatu Obejrzen ie listy
studentó w p rzez pracownika dziek anatu
«e xtend»
«e xte nd»
«i nc lu de»« exten d»
«exten d»
«exten d»« extend »
«i ncl ud e»«exten d»
36
5 2
1 712 10
811
913
4 1817
151614
Jaka ś zm iana wyma gani.Bard zo i stotn a zm iana wyma gani a
Jakaś zmia na wy maga ni.Bardzo ist otna zmia na wymaga nia
Jakaś zmi ana w ymag ani.Bardz o is totna zmi ana wymag ania
Jaka ś zmi ana wymag ani.Bard zo is totn a zmi ana wyma gania
UżytkownikZamawiający
1 2 3
Analityk wymagań
Software Engineering Slide 1.2 A. Ambroziewicz, M. Śmiałek
What is Software Engineering?
Software engineering (SE) is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.
-- IEEE definition
Software Engineering Slide 1.3 A. Ambroziewicz, M. Śmiałek
Complexity of software engineering
„Computer programming is definitely the most complicated intellectual task ever performed by the humans. Ever.”
Gerald M. Weinberg – „Understanding the professional programmer”, 1988
The problem: Code contains hundreds of thousands of lines (for average
commercial systems) Code instructions grouped in procedures; the code still contains
thousands of procedures Procedures grouped in modules (classes, components); the code
contains hundreds of modules
Software Engineering Slide 1.4 A. Ambroziewicz, M. Śmiałek
Software engineering isn’t only about coding!
Zamawiający Programista
Środowisko
Model środowiska
Kod
Model kodu
Environment Code
Client Programmer
Environment model Code model
Software Engineering Slide 1.5 A. Ambroziewicz, M. Śmiałek
What is software engineering about?
Software engineering is about managing complexity Complexity of the client’s needs Complexity of code
Software engineering is about delivering what the client really wants
Software engineering is about organizing teamwork Small teams (2-6 people) Large teams (tens of people) Separated teams (eg. overseas development)
Software Engineering Slide 1.6 A. Ambroziewicz, M. Śmiałek
Software engineering projects – success criteria
The project is within its budget The project is within its time limit (deadline) The system delivered fulfils the real needs of the customer
Software engineering project
These are my needs
This is a system fulfilling your
needs
Software Engineering Slide 1.7 A. Ambroziewicz, M. Śmiałek
First NATO conference on software engineering (1967): “there is a crisis”
Roger Pressman: „it is a chronic affliction”
0%
20%
40%
60%
80%
100%
1994 2004
Sukces Porażka ZagrożoneSuccess Failure Affected
Software Engineering Slide 1.8 A. Ambroziewicz, M. Śmiałek
Typical symptoms of the chronic affliction
Unsatisfied clients “this is not the system we meant originally!” “none of our clerks will be able to use it!”
Unsatisfied suppliers “so, what do they want from us?” “why do they change their mind all the time?” “but we have done such a hard work!”
Quarrels about the scope “you want us to build a system twice as large as specified in the
contract!” “but these functions were to be delivered only in the next version!” “you did not deliver the functionality stated in paragraph 24 point 5a
of the contract!” – “oh, yes, we did!”
Software Engineering Slide 1.9 A. Ambroziewicz, M. Śmiałek
Typical symptoms of the chronic affliction (cntd.)Chaotic management of changing requirements “hey, guys, add just a little tiny table in the middle of this window, it
will cost you almost nothing” “we thought that this change will not be important for you at all…”
Programmers working 24/7 “we want a pizza at midnight and a lot of Jolt Cola!” “we want ten more programmers!”
Stress at the end of the project “this system works like a snail!” “but we didn’t yet deliver half of the functionality!”
No repeatability of the development process “so, how much will we overrun the budget this time?” “so, how will we write the requirements specification this time?”
Software Engineering Slide 1.10 A. Ambroziewicz, M. Śmiałek
Causes of the affliction
Imprecise software specifications “does ‘account’ mean a ‘user account’ or a ‘banking account’?”
Bad communication “oh, so this form is so important…”
Lack of proper architecture “so, what machine will we install this printer subsystem on?”
No management of the system’s complexity “our database has 1500 tables and 2000 classes!”
Very late discovery of serious ambiguities “and only now you tell me that this procedure hasn’t got parameter
X!”
Software Engineering Slide 1.11 A. Ambroziewicz, M. Śmiałek
Causes of the affliction (cntd.)
Insufficient testing “it seems that it works…”
Subjective judgements “this specification is quite good…”
No change management “so, why is this form that important?”
Not using CASE tools “we only need a good compiler with an IDE!”
Too late verification of the client’s needs “you should have asked us earlier what colour should the screens
have!”
Software Engineering Slide 1.12 A. Ambroziewicz, M. Śmiałek
Cure for the affliction (1)
Jim Johnson, Standish Group: It is getting better (see the statistics), but why? People (software development organizations) start using systematic
processes!
So, what do we need?
meth·od·ol·o·gy [meth-uh-dol-uh-jee]
A set or system of methods, principles, and rules for regulating a given discipline, as in the arts or sciences.
(Random House Unabridged Dictionary 2006)
Methodology!
Software Engineering Slide 1.13 A. Ambroziewicz, M. Śmiałek
Cure for the affliction (2)
Software development methodology: Notation – a modelling language to denote all the software
development products (leading to code) Techniques – a description of activities that produce the software
development products (written with the notation) Technical process – ordering of activities into a coherent flow of
work that produces the final software system
Software Engineering Slide 1.14 A. Ambroziewicz, M. Śmiałek
Notation for requirements modellingThe notation should reduce complexity of requirements
The notation should be easilytransformable into design and then – code
What should we produce with the notation? models that describe the complex user needs models that allow for managing complex
dependencies between these needs models that are understandable by the users (a
picture is worth more than a thousand words) models that can be later used by the architects
to design the system
What language allows for producing such models?
Unified Modelling Language
Methodology!
Software Engineering Slide 1.15 A. Ambroziewicz, M. Śmiałek
Notation reduces complexity
UML allows for realizing abstraction – capability of concentrating on the most important elements; constructing general notions on the basis of detailed ones
Town
House
Window
PublicUtility
Building
Software Engineering Slide 1.16 A. Ambroziewicz, M. Śmiałek
Modelling reduces complexity
Model 1.a representation, generally in miniature, to show the construction or appearance of something
2.a simplified representation of a system or phenomenon, as in the sciences or economics, with any hypotheses required to describe the system or explain the phenomenon, often mathematically.
Software Engineering Slide 1.17 A. Ambroziewicz, M. Śmiałek
Techniques for requirements elicitation and specification
Analysing the documents Reading documents supplied by
the client to discover the real needs Underlining nouns, verbs Identifying paragraphs of text as requirements
Working one-to-one Interviews with he clients and with the users Apprenticeship (the tutor and his/her student)
Group work Group requirements modelling sessions: users, analysts discover
requirements and write them down in a chosen visual notation Brainstorms
Methodology!
Software Engineering Slide 1.18 A. Ambroziewicz, M. Śmiałek
Technical process and requirements (1)
Waterfall lifecycle All the activities lead from the initial user
needs to the final system in “one go”Methodology!
Requirements
Implementation
Design
Verification
Maintenance
Software Engineering Slide 1.19 A. Ambroziewicz, M. Śmiałek
Technical process and requirements (2)
Iterative lifecycle Activities are repeated in several smaller cycles to reach the final system in several increments
Methodology!
Initialplanning
Requirements
Analysis
ImplementationClient
pays Validation
Design
Software Engineering Slide 1.20 A. Ambroziewicz, M. Śmiałek
severaltimes
Practice 1 – Organize activities of your lifecycle : waterfall vs. iterative
User’s business needs
User Requirements Phase
System Requirements Phase
Architectural Design Phase
Detailed Design Phase
Transfer Phase
SRP
ADP
DDP
TP
Delivered system
?
Software Engineering Slide 1.21 A. Ambroziewicz, M. Śmiałek
Waterfall vs. Iterative (1)
Software Engineering Slide 1.22 A. Ambroziewicz, M. Śmiałek
Waterfall vs. Iterative (2)
Software Engineering Slide 1.23 A. Ambroziewicz, M. Śmiałek
Which technical process is better?
Waterfall Organizes all the activities into “analysis” and “synthesis” – in accordance to
how humans solve problems Allows for easy resource management (analysts, architects, etc.) Gives a clear path from the “beginning” to the “end” BUT: hides all the problems until the very end of the project! Very risky –
that’s why many projects overrun the deadline and budget! BUT: every change in requirements causes chaos!
Iterative Significantly reduces the risk because problems are uncovered after every
iteration Allows for managing change in a very natural way Allows the user to discover the real needs – produces better systems Allows the development team to “learn” the project That’s why many projects succeed – they use iterative lifecycle BUT: is more complicated, can cause significant overhead
Software Engineering Slide 1.24 A. Ambroziewicz, M. Śmiałek
Technical process - the hybrid
Spiral lifecycle Hybrid: Activities are repeated to reach the final system in several prototypes (prototyping-in-stages)
Intended for large, expensive and complicated projects.
Methodology!
Software Engineering Slide 1.25 A. Ambroziewicz, M. Śmiałek
Technical process and requirements
Requirements in the software lifecycle
Possibility 1: all the requirements gathered before we start developing the system (waterfall)
Possibility 2: scope of the system determined before we start developing the system, detailed requirements determined during development (formal iterative)
Possibility 3: vision of the system determined before we start developing the system, all requirements determined during development (agile)
Methodology!
Software Engineering Slide 1.26 A. Ambroziewicz, M. Śmiałek
Why are requirements so important?
Software Engineering Slide 1.27 A. Ambroziewicz, M. Śmiałek
Why is methodology so important?
Software Engineering Slide 1.28 A. Ambroziewicz, M. Śmiałek
Methodology, how does it work?
?
Notation
TechniquesTechnical process
Software Engineering Slide 1.29 A. Ambroziewicz, M. Śmiałek
Software engineering methodologies
Formal methods:
based on assumption that performing appropriate mathematical analyses can contribute to the reliability and robustness of a design
aim at detailed documentation of each step of a development process
Agile methods :
encourage frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability
aim at rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals
99% of the projects I've seen come from a Formal background and implement Agile practices incrementally
--- Roy Osherove
Software Engineering Slide 1.30 A. Ambroziewicz, M. Śmiałek
Software engineering methodologies
Formal methods: IBM: Rational Unified Process (RUP) Borland: Application Lifecycle Management (ALM) Microsoft: Microsoft Solution Framework (MSF) Eiffel Software: Eiffel Development Framework OPEN Consortium: O-O Process Environ. and Notation (OPEN) OMG: Model-Driven Architecture (MDA) – not a full methodology
Agile methods – Agile Alliance: Kent Beck: eXtreme Programming (XP) DSDM Consortium: Dynamic Systems Dev. Method Alistair Cockburn: Crystal Jim Highsmith: Agile Project Management Scott Ambler: Agile Modeling (AM) – not a full methodology
Software Engineering Slide 1.31 A. Ambroziewicz, M. Śmiałek
Software engineering methodologies (cntd.)
Methodologies defined as standards European Space Agency (ESA): PSS-05-0 (ESA Software
Engineering Standards, older standard), ECSS-E-40 (Space Engineering: Software, current standard)
US Department of Defense (DoD): MIL-STD-498 (Software Development and Documentation)
International Standards Organization (ISO): ISO/IEC 12207 (Software Lifecycle Processes)
These standards define mostly the lifecycle process and documentation. No definition of modelling notation or techniques. This means that they are not full methodologies.
Software Engineering Slide 1.32 A. Ambroziewicz, M. Śmiałek
Best practices found in methodologies
Technical process: Practice 1: Organize activities of your lifecycle – otherwise you will
have an organizational chaos
Notation: Practice 2: Document all your decisions – otherwise you will quickly
forget why you did what you did
Techniques: Practice 3: Manage requirements – otherwise you will lose the goal Practice 4: Manage change – otherwise you will be overwhelmed
with new “system features” Practice 5: Manage quality – otherwise you will have a dissatisfied
client Practice 6: Manage complexity of the system – otherwise you will
produce a bowl of spaghetti
Software Engineering Slide 1.33 A. Ambroziewicz, M. Śmiałek
severaltimes
Practice 1 – Organize activities of your lifecycle : waterfall vs. iterative
User’s business needs
User Requirements Phase
System Requirements Phase
Architectural Design Phase
Detailed Design Phase
Transfer Phase
SRP
ADP
DDP
TP
Delivered system
?
Software Engineering Slide 1.34 A. Ambroziewicz, M. Śmiałek
Practice 2 – Document all your decisions : commented code vs. documents vs. models
System rejestruje samochód znalezionego właściciela.
System powiadamia rejestratora o zarejestrowaniu samochodu.
System powiadamia rejestratora o nieznalezieniu właściciela.
[nie][tak]
sd Diagram sekwencj i
:Rejes tra tor
:Właściciel s :Samochódapl :GUI znaleziony:Właściciel
loop znajdź
[ porówn aj_da ne=fa lse ]
z are jes truj_s a mochód(n azwis ko)
b oolea n:=p orówna j_dan e(naz wis ko)
za zna cz _rejes tra cję ()
rej estruj()
Codemodel
sd Diagram sekwencj i
:Rejes trat or
:Właściciel s :Samochódapl :GUI znaleziony:Właściciel
loop znajdź
[p orównaj _dane =fals e]
z arej estruj_s am och ód(na zwis ko)
boo lean: =por ównaj_d ane(n azwis ko)
z az nacz_re jes trację()
re jes truj()
dd Diagram wdrożenia
stacja_pc
« j ar»R eje stracj a . ja r
serwer_aplikacyjny
serw er_bazy_danych
« SQL db »DB Acce ss.d b
« j a r»Wyd zi a l . ja r
«j a r»Sta tystyki . ja r
ad Diagram czynności
Rozpoc zęci e rejes trac ji
Zakońc zenie rejes tracj i
Rejestrator podaje nazwisko do rejestracji.
System wyszukuje właściciela o podanym nazwisku.
czy z nale z niono ?
System rejestruje samochód znalezionego właściciela.
System powiadamia rejestratora o zarejestrowaniu samochodu.
System powiadamia rejestratora o nieznalezieniu właściciela.
[nie][tak]
id Diagra m kom ponen tów
Aplik acjaR ejestra cji
DaneOsob oweIOsoby
DaneR ejestr acji
IRejestrac ja IStaty styki
Utrwalan ieDany chIDane
Software Engineering Slide 1.35 A. Ambroziewicz, M. Śmiałek
Which notation is better?
Commented code Very good practice – allows us and other programmers to maintain
code in the future BUT: documents only local decisions within individual procedures
and modules
Documents Can be written according to standards (templates) No special tools needed (word processor) BUT: tend to become out of date (people don’t like documenting…) BUT: hard to manage dependencies between documents
Models Visual notation is superior over text – map vs. words! Code can be generated semi-automatically from models BUT: needs special tools (CASE tools)
Software Engineering Slide 1.36 A. Ambroziewicz, M. Śmiałek
Model as a map
Code or requirements can be better understood if described with a “map”.
Visual notation allows for making the modelled domain simpler.
package pwum l.diagram management ;public class Dia gramWindow extend s JInternalFra me
implem ents InternalFr ameLi stener {protect ed DiagramID diagra mID;protect ed DiagramCanv as diagra mCanv as;protect ed JScrollPane diagra mScro llPan e;
setIconifiable(true);setResizable(true);diagramCanvas= new DiagramCanvas(diagramID);diagramScrollPane= new JScrollPane(diagramCanvas);setContentPane(diagramScrollPane);setLocation(210,10);setSize(Settings.APPLICATION_WINDOW_X_SIZE /2,
static int MINIMAL_WIDT H; // we will ev aluate it after "em pty" class is createdstatic int MINIMAL_HEIG HT;
final static int FIE LD_ALIGN_ LEFT = 0;final static int FIE LD_ALIGN_ CENTER = 1;final static int LE FT_MARGIN = 10;final static int VERTICAL_SPACE = 4;int y Pointer;
boolean sizeFound = false;
public ClassApperance(ClassApperanceID newObjectID, DiagramID diagramID , ClassDataI D classID) {
static int MINIMAL_WIDTH; // we will evaluate it after "em pty" class is createdstatic int MINIMAL_HEIG HT;
final static int FIE LD_ALIGN_LEFT = 0;final static int FIE LD_ALIGN_CENTER = 1;final static int LE FT_MARGIN = 10;final static int VERTICAL_SPACE = 4;int yPointer;
boole an sizeFound = false;
public ClassApperance(ClassApperanceID newObjectID, DiagramI D diagramID , ClassDataI D classID) {
setIconifiable(true);setResizable(true);diagramCanvas= new DiagramCanvas(diagramID);diagramScrollPane= new JScrollPane(diagramCanvas);setContentPane(diagramScrollPane);setLocation(210,10);setSize(Settings.APPLICATION_WINDOW_X_SIZE /2,
setIconifiable(true);setResizable(true);diagramCanvas= new DiagramCanvas(diagramID);diagramScrollPane= new JScrollPane(diagramCanvas);setContentPane(diagramScrollPane);setLocation(210,10);setSize(Settings.APPLICATION_WINDOW_X_SIZE /2,
static int MINIMAL_WIDTH; // we will ev aluate it after "em pty" class is createdstatic int MINIMAL_HEIG HT;
final static int FIE LD_ALIGN_LEFT = 0;final static int FIE LD_ALIGN_CENTER = 1;final static int LE FT_MARGIN = 10;final static int VERTICAL_SPACE = 4;int yPointer;
boolean sizeFound = false;
public ClassApperance(ClassApperanceID newObjectID, DiagramI D diagramID , ClassDataI D classID) {
Reje stra tor po daje nazw isk o do reje stra cji.
Syste m w yszukuje w ła ści cie la o podanym nazw is ku.
c z y zn ale zn ion o?
System re je struje s amoc hód zna lezion ego w ła ści cie la.
Syste m pow iadamia rejes tratora o zareje strow a niu sa mocho du.
Syste m pow ia damia rejes trato ra o nie znal ezieniu w ła ści cie la.
[nie ][t ak]
ad D ia gra m c zynnoś ci
Roz po cz ęc ie rej estra cj i
Za końc z eni e re jest rac ji
Reje stra tor po daje nazw isk o do reje stra cji.
Syste m w yszukuje w ła ści cie la o podanym nazw is ku.
c z y zn ale zn ion o?
System re je struje s amoc hód zna lezion ego w ła ści cie la.
Syste m pow iadamia rejes tratora o zareje strow a niu sa mocho du.
Syste m pow ia damia rejes trato ra o nie znal ezieniu w ła ści cie la.
[nie ][t ak]
ad D ia gra m c zynnoś ci
Roz po cz ęc ie rej estra cj i
Za końc z eni e re jest rac ji
Reje stra tor po daje nazw isk o do reje stra cji.
Syste m w yszukuje w ła ści cie la o podanym nazw is ku.
c z y zn ale zn ion o?
System re je struje s amoc hód zna lezion ego w ła ści cie la.
Syste m pow iadamia rejes tratora o zareje strow a niu sa mocho du.
Syste m pow ia damia rejes trato ra o nie znal ezieniu w ła ści cie la.
[nie ][t ak]
cd Diagram klas
Samoch ód
Właśc iciel
Dowó d Rej estracyj ny
wsp ółwł asno ść
udoku mentowa nie
przynależ noś ć
własn ość
cd Diagra m klas
Samoch ód
Właś ciciel
Dowód Rej es tracyjny
ws półwł asno ść
udok umentowanie
przynależ ność
wł asno ść
cd Diagram klas
Samoch ód
Właśc iciel
Dowó d Rej estracyj ny
wsp ółwł asno ść
udoku mentowa nie
przynależ noś ć
własn ość
Design products
Generallevel
Detailedlevel
Generate!
Software Engineering Slide 1.38 A. Ambroziewicz, M. Śmiałek
What is a requirement?
Requirement is a property of the final product (here: a software system) that it needs to possess in order to fulfil the client’s needs. This property can determine the way in which the system should function or specify a quality feature of the system.
Requirement
Software System
!
?!
Requirements control the software development process
Requirements are there to verify that the system was built to its purpose
Software Engineering Slide 1.39 A. Ambroziewicz, M. Śmiałek
How do we classify requirements?
By level of detail – one level is not enough (we need to manage complexity) User Requirements – general requirements defining the scope of
the system: “how much will the system do?”, “how much will the system cost us?”, “what business benefits will the system offer?”
Software Requirements – detailed requirements defining specific characteristics of the system: “how will the system ‘talk’ with the user?”, “what data will the system handle?”
By their meaning for the system Functional requirements – what the system will do? Non-functional requirements – what quality will the system have? Vocabulary requirements – what data will the system handle? Environmental constraints – what limits are there in the client’s
environment (technical or business)?
Software Engineering Slide 1.40 A. Ambroziewicz, M. Śmiałek
How to manage requirements?
Divide your requirements document or model into “chunks”. Each chunk is a single requirement.
Individual requirements are related one to another and related to design products.
Requirements are given attributes (numbers, priorities, etc.).
How to divide the requirements into chunks? This course is to give answer to this!
User RequirementsModel
User RequirementsModel
ad Dia gram czynno ści
Rozp oczęci e reje stracji
Zakończen ie rej estracj i
Rejes trator podaje nazw isko do re jestra cji.
System w yszuk uje wł aścic iela o pod anym nazw isku.
czy znale zniono ?
System rejest ruje s amoch ód znalez ioneg o właś ciciel a.
System p owiad amia r ejestr atora o zarejes trowa niu sa moch odu.
System powia damia rejes trator a o niez nalez ieniu w łaści ciela.
[nie]
[tak]
ad Dia gram czynno ści
Rozp oczęci e reje stracji
Zakończen ie rej estracj i
Rejes trator podaje nazw isko do re jestra cji.
System w yszuk uje wł aścic iela o pod anym nazw isku.
czy znale zniono ?
System rejest ruje s amoch ód znalez ioneg o właś ciciel a.
System p owiad amia r ejestr atora o zarejes trowa niu sa moch odu.
System powia damia rejes trator a o niez nalez ieniu w łaści ciela.
[nie]
[tak]
1 2
3
12
34
ad Dia gram czynno ści
Rozp oczęci e reje stracji
Zakończen ie rej estracj i
Rejes trator podaje nazw isko do re jestra cji.
System w yszuk uje wł aścic iela o pod anym nazw isku.
czy znale zniono ?
System rejest ruje s amoch ód znalez ioneg o właś ciciel a.
System p owiad amia r ejestr atora o zarejes trowa niu sa moch odu.
System powia damia rejes trator a o niez nalez ieniu w łaści ciela.
[nie]
[tak]
dd Diagram wdrożenia
stacja_pc
«jar »Rej es trac ja.ja r
serwer_aplikacyjny
serwer_bazy_danych
«SQL db»DBA ccess.db
«jar»W ydzia l.jar
«ja r»Sta tys tyki.jar
id Diagra m kom ponen tów
Aplik acjaR ejestra cji
DaneOsob oweIOsoby
DaneR ejestr acji
IRejestrac ja IStaty styki
Utrwalan ieDany chIDane
cd Di agram klas
Sam ochód
Właściciel
Dowód Rej est racyj ny
w spół własność
udoku ment owanie
przynależno ść
w łasność
cd Di agram klas
Sam ochód
Właściciel
Dowód Rej est racyj ny
w spół własność
udoku ment owanie
przynależno ść
w łasność
Software Engineering Slide 1.41 A. Ambroziewicz, M. Śmiałek
How do requirements control the software development process?
Individual requirements (mainly – functional) can control the technical process.
This way, the system is developed in accordance with the user’s needs.
SO Da
Pracownik dydaktyczny
Student
Przej rzenie planu zajęć z
zarządzaniem ocenami
Dodanie sprawdzianu
Modyfikacja sprawdzianu
Wprowadzenie ocen cząstkowych
Zatwierdzenie ocen końcowych
Wprowadzenie kryteriów
obliczania oceny końcowej
Sprawdzenie ocen z zajęć
Uprawniony pracownik dydaktyczny
Przejrzenie planu zajęć
«ex te n d»«ex te nd »
SODa
Obejrzenie listy studentów
Potwierdzenie złożenia indeksu
Potwierdzenie skreślenia studenta
Przejrzenie historii osiągnięć
studenta
Dokonanie rejestracji studenta po
terminie
Obejrzenie listy studentów przez
Dziekana
Potwierdzenie wydania indeksu
Dokonanie zmiany rejestracj i
studenta
Przydzielenie studentów do grup
Dziekan
Pracownik dziekanatu Obej rzenie listy
studentów przez pracownika dziekanatu
«extend»
«extend»
«i nclude»«extend»
«extend»
«extend»«extend»
«include»«extend»
36
5 2
1 712 10
811
913
4 1817
151614
Jakaś zmiana wymagani.Bardzo istotna zmiana wymagania
Jakaś zmiana wymagani.Bardzo istotna zmiana wymagania
Jakaś zmiana wymagani.Bardzo istotna zmiana wymagania
Jakaś zmiana wymagani.Bardzo istotna zmiana wymagania
UżytkownikZamawiający
1 2 3
Analityk wymagańAnalysts
Software Engineering Slide 1.42 A. Ambroziewicz, M. Śmiałek
Summary: methodologies – what’s the problem?
People don’t use methodologies
Even if people try to use methodologies, they don’t use them correctly. Formal methodologies
become “too heavy” – documents overwhelm the process (see: analysis paralysis)
Agile methodologies become too light – “code hacking” substitutes systematic techniques and adequate documenting
?
Software Engineering Slide 1.43 A. Ambroziewicz, M. Śmiałek
Summary: methodologies – what’s the answer?
Modelling! Instead of writing heavy specifications – draw simple to understand
diagrams
Iterations! Instead of doing everything in one “big bang” (oh, what a mess!) –
divide the project into several smaller “bangs”
Requirements drive the process! Instead of writing the system based on vague vision – define very
precise requirements “chunks” and assure that they are realized “one by one”
Software Engineering Slide 1.44 A. Ambroziewicz, M. Śmiałek