1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
|
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Q1. Software Process Model - Waterfall — adast.xyz</title>
<link rel="icon" type="image/x-icon" href="images/favicon.ico">
<link rel="stylesheet" href="styles/style.css">
</head>
<body>
<header>
<a href="/" class="homepage-link">adast.xyz</a>
</header>
<h1 id="q1.-software-process-model---waterfall">Q1. Software Process Model - Waterfall</h1>
<h2 id="what-is-software-engineering-a-response-to">What is software engineering a response to?</h2>
<ul>
<li>Increasing system complexity.</li>
<li>Failure to use software engineering methods.</li>
</ul>
<p>There are no universal notations, methods or techniques for software engineering.
This is because different types of software require different approaches.</p>
<p>There are cases where software projects or software can fail.</p>
<h3 id="increasing-system-complexity">Increasing system complexity</h3>
<p>As new software technology helps us to build bigger, more complicated systems, the requirements change.</p>
<p>Systems need to be developed and delivered faster meaning more complicated systems are required.
This means more requirements for the systems.</p>
<h3 id="failure-to-use-software-engineering-methods">Failure to use software engineering methods</h3>
<p>It is easy to develop programs without using software engineering techniques… BUT
This can result in more expensive software development and less reliable, readable systems.
To solve this issue, more education and training is required on these techniques.</p>
<h2 id="software-engineering-process-activities">Software engineering process activities</h2>
<h3 id="software-specification">Software specification</h3>
<p>This is where the clients and the developers define the software that should be produced.
This is where the software is limited in terms of what is should be.</p>
<h3 id="software-development">Software development</h3>
<p>This is where the software is designed and programmed.</p>
<h3 id="software-validation">Software validation</h3>
<p>This step ensures that the software does what the client requested.</p>
<h3 id="software-evolution">Software evolution</h3>
<p>When software is modified to meet client’s or the market’s new requirements.</p>
<h2 id="what-is-a-software-process-model">What is a software process model</h2>
<p>A software process model is a set or related activities that leads to a software product.
An abstract descriptions of high level software processes.
These can be used to explain different approaches to software development.
These can be interpreted as frameworks that can be expanded and personalized to create more specific software engineering processes.</p>
<h3 id="waterfall-model">Waterfall model</h3>
<p>The model takes the fundamental software process activities.
Seperate process phases:
- Requirement specification
- Software design
- Implementation
- Test</p>
<h3 id="incrementaliterative-development">Incremental/iterative development</h3>
<p>This approach combines the activities with specification, development and validation.
The system is developed in a series of versions (increments)
Each version adds some functionality on top of the previous version.</p>
<h3 id="integration-and-configuration">Integration and configuration</h3>
<p>This approach depends on the availability of reusable components or systems.
The systemdevelopment process focuses on configuring these components to be used in new contexts and integrate them with the system.
This lets you reuse code from previous projects and save time and money.</p>
<h2 id="waterfall-model-1">Waterfall model</h2>
<p>Activities are done in a sequence.
Handover of workproducts between phases and milestones are used to monitor progress.
Waterfall model is an example of a plan-driven process.
You are supposed to have all of the process activities and phases planned out before you start development.
The phases in the model directly reflect the fundamental development activities.</p>
<h3 id="requirements-analysis-and-definition">Requirements analysis and definition</h3>
<p>The systems services, limits and goal and made concrete through consulting with the users.
They are then defined in detail and are used as the system specification.</p>
<h3 id="system-and-software-design">System and software design</h3>
<p>The overall system architecture is established in this phase.
Identify and describe the fundamental system abstractions and their relations (UML)</p>
<h3 id="implementation-and-unit-testing">Implementation and unit testing</h3>
<p>The design is implemented in the indivivual program parts.
The design is tested to verify that it meets the specification.</p>
<h3 id="integration-and-system-testing">Integration and system testing</h3>
<p>The individual program parts are integrated and the whole system it tested.
The software is delivered to the client.</p>
<h3 id="operation-and-maintenance">Operation and maintenance</h3>
<p>The system is now installed and in use.
The system is maintained to any issuse that weren’t found earlier.
The system is improved over time.</p>
<h2 id="when-should-you-consider-using-waterfall">When should you consider using waterfall?</h2>
<p>For software that needs to be flexible while it is being developed.</p>
<h3 id="embedded-systems">Embedded systems</h3>
<p>The software must interface with hardware.
In this case the hardware is not flexible, thus the software must be.</p>
<h3 id="critical-systems">Critical systems</h3>
<p>When total security is a requirement of the specification and design.
These systems must have finite specifications and design documents.</p>
<h3 id="large-software-systems">Large software systems</h3>
<p>Part of a larger system being developed by several parties.
This makes finite specifications extremely necessary.</p>
<h2 id="how-can-i-decide-on-waterfall---analyse-home-ground">How can I decide on waterfall? - analyse home ground</h2>
<p>When one phase ends another begins.
Steps come ordered and don’t allow for going back and redoing parts. (waterfall flows only down)
When the requirements are mostly unchanging.</p>
<h3 id="plan-driven-versus-agile-processes">Plan driven versus agile processes?</h3>
<p>Activities in sequence versus all activities at the same time.
Agile development is very flexible and the requirements may be constantly changing. </p>
<h2 id="incremental-model">Incremental model</h2>
<p>You can iterate within increments and the increments can be planned.
You work within fixed time slots and update the project backlog continuously.
Incremental is an agile process, where you end with multiple versions that you can show the clients as the project progresses.
This allows for the client to come with feedback along the way.</p>
<h2 id="integration-and-configuration-1">Integration and configuration</h2>
<p>Development risk is reduced by reuse but there is the risk of not being able to make the desired changes at all or in the time frame.
Most projects have some level of code reuse.
This is often informal.
This reuse requires looking for the existing code, changing them to meet the requirements and integrating them with the new code.</p>
<h1 id="q2.-software-process-model---incrementaliterative">Q2. Software Process Model - Incremental/iterative</h1>
<p>The incremental development is based on the idea that:
1. Develop in prototypes.
2. Get feedback from the users and others.
3. Develop over multiple versions until the required system is produced.</p>
<p>Incremental development is the most common approach to developing applications and software. </p>
<h2 id="can-it-be-both-plandriven-and-agile">Can it be both plandriven and agile?</h2>
<p>Yes, it can be either one or a mix of both.</p>
<h3 id="plan-driven-approach">Plan-driven approach</h3>
<p>Identify the system increments in advance.
A predictable waterfall plan is split into parts.</p>
<h3 id="agile-approach">Agile approach</h3>
<p>The early increments are identified.
The later increments depend on progress and the clients priorities.
You work in fixed timeframes and update the full project backlog as you go.</p>
<h3 id="agile-manifest-balancemix">Agile-manifest (balance/mix)</h3>
<p>Focus on the individuals and teamwork rather than the processes and tools.
Good software comes before comprehensive documentation.
Work with the client instead of using contract work.
Deal with changes instead of sticking to the plan.</p>
<h2 id="what-are-advantages-of-incremental">What are advantages of incremental?</h2>
<ol>
<li><p>Development costs are reduced
The amount of analysis and documentation that has to be redone is much less than waterfall.</p></li>
<li><p>It is easier to get client feedback
The clients can comment on demonstrations of the different versions and see the progress.</p></li>
<li><p>Earlier delivery of new software
New features can be made available even if they are not fully completed.</p></li>
</ol>
<h2 id="what-disadvantages-are-there">What disadvantages are there?</h2>
<ol>
<li><p>The project is not visible
Managers can have difficulty measuring progress.
It would be a waste of resources to produce documents that reflect the different versions.</p></li>
<li><p>The system structure can get messy over time
Changes lead to messy code.
It gets increasingly difficult to add new functions to a system.
Large, complex systems with large teams struggle with incremental for this reason.
Large systems need a stable architecture.
Responsibility of the different teams needs to be clear with respect to this architecture.
This has to be done in advance.</p></li>
</ol>
<h1 id="q3.-software-process-model---integration-and-configuration">Q3. Software Process Model - Integration and configuration</h1>
<h2 id="what-are-the-phases">What are the phases?</h2>
<h3 id="requirements-specification">Requirements specification</h3>
<p>The inital requirements are suggested
They don’t need to be developed in more detail.
They should include short descriptions of important requirements and desired functionality.</p>
<h3 id="software-discovery-and-evaluation">Software discovery and evaluation</h3>
<p>With the overview of the requirements, components are searched for that provide the necessary functionality.</p>
<h3 id="requirements-refinement">Requirements refinement</h3>
<p>The requirements are polished with the knowledge of the reusable components that were found.</p>
<h3 id="application-system-configuration">Application system configuration</h3>
<p>If an application that meets the requirements is available, it is configured for use in the new system.</p>
<h2 id="advantagesdisadvantages">Advantages/disadvantages</h2>
<p>This model reduces the amount of software that must be developed.
This in turn, reduces the costs and risks.</p>
<p>You usually don’t have control of the software that is being reused.
This can include for example how and when new version are released and how the functionality is changed.</p>
<h1 id="q4.-comparison-of-plandriven-and-agile-including-homeground">Q4. Comparison of plandriven and agile including Homeground</h1>
<h2 id="what-is-the-difference-between-plandriven-and-agile">What is the difference between plandriven and agile?</h2>
<h3 id="plandriven">Plandriven</h3>
<p>Plandriven means the desired result can be predicted.
Plandriven = waterfall.
Plandriven is an approach where the development process is planned in detail.
A project plan is created that registers the work that needs to done, who should do it the development plan and the work tools.
Managers use this plan to support project decisions and as a way to measure progress.
This is a traditional approach to software development.</p>
<h3 id="agile">Agile</h3>
<p>Agile expects changes and frequent user inspection to get the best results.
Agile = Iterative, more detailed Scrum and XP
Agile methods are iterative, the software is developed and delivered in stages.
These versions are not planned in advance but are chosen underway.
Decisions on what should be included in a version depend on the clients priorities.</p>
<h2 id="how-does-bhmturner-define-primary-factors">How does Böhm/Turner define primary factors?</h2>
<h3 id="application">Application</h3>
<h4 id="agile-1">Agile</h4>
<p>Goal: to handle changes in the project.
Small teams.
Environment is turbulent and fast-paced, project focused.</p>
<h4 id="plandriven-1">Plandriven</h4>
<p>Goal: predictability, stability and security.
Larger teams and projects.
Environment: stable, few changes, organisation focused.</p>
<h3 id="management-onsite-qualitative-control-tacit-knowledge">Management (onsite, qualitative control, tacit knowledge)</h3>
<h4 id="agile-2">Agile</h4>
<p>Customer relations: dedicated clients on site, focused on prioritised changes
Planning and control: qualitative control. Who and how doensn’t matter as long as it gets done.
Communications: Tacit knowledge. People do things without needing much explanation or discussion.</p>
<h4 id="plan-driven">Plan-driven</h4>
<p>Customer relations: More formal and infrequent. Focused on contract decisions.
Planning and control: Documented plans, quantitative control. It is important to know who does what.
Communications: Explicit. Plans must be discussed and verbalized and shared with the others.</p>
<h3 id="technical">Technical</h3>
<h4 id="agile-3">Agile</h4>
<p>Requirements: can withstand unpredictability.
Development: simple design, small increments, refactoring is assumed to be cheap.
Test: Test cases define the requirements.</p>
<h4 id="plan-driven-1">Plan-driven</h4>
<p>Requirements: Formal project, user interface, quality, predictable requirements.
Development: Comprehensive design, larger intervals, refactoring is costly.
Test: Documented testplans and procedures.</p>
<h3 id="people">People</h3>
<p>Cockburn characteristics can describe a programmers personality.
One type may be more favourable than another depending on agile/plan-driven approach. </p>
<h2 id="5-axis-on-the-home-ground-decision-tool">5 axis on the Home Ground Decision tool</h2>
<ul>
<li>Criticality: impact of defects</li>
<li>Personell: average cockburn type</li>
<li>Dynamism: % requirement change per month</li>
<li>Culture: % thriving on chaos vs. order</li>
<li>Size: # of personnel</li>
</ul>
<h2 id="what-is-continuous-integration-and-how-does-it-relate-to-agile">What is continuous integration and how does it relate to agile?</h2>
<p>As soon as the work on a task is complete, it is integrated into the whole system.
After such integration, all the unit tests must pass.
Continuous integration uses tools to automate the process.
Depends on unit tests.
Does NOT remove the need for tests.</p>
<h2 id="prototype-development">Prototype development</h2>
<ul>
<li>Prototype plan: establish objectives</li>
<li>Outline definition: define functionality</li>
<li>Executable prototype</li>
<li>Evaluation report</li>
</ul>
<h1 id="q5.-key-features-of-scrum">Q5. Key features of SCRUM</h1>
<p>Openness of all work.
Respect each other.
Focus on the common goal.
Courage for difficult decisions.
Duty to the common goal.</p>
<p>3 roles.
5 events.
3 artifacts.</p>
<h2 id="assets">Assets</h2>
<ul>
<li>Scrum board</li>
<li>Project burndown</li>
<li>Sprint burndown</li>
</ul>
<h2 id="three-pillars">Three pillars</h2>
<p>Transparency: Everyone knows what needs to be done and who is doing what.
Inspect: Keep an eye on where we are heading (daily meetings).
Adapt: Change if it is necessary.</p>
<h2 id="core-values">Core values</h2>
<p>Commitment: to reach the sprint goal.
Focus: on what needs to be done in the sprint.
Openness: Communication is key, don’t hide issuse.
Respect: for each other
Courage: to do the right thing</p>
<h2 id="typical-errors">Typical errors</h2>
<p>Scrum master is a manager.
No communication with the client.
New tasks are added to the sprint backlog in the middle of a sprint.</p>
<h2 id="daily-scrum">Daily SCRUM</h2>
<p>Inspect progress towards the sprint goal.
Adjust the backlog accordingly.
Update (how far are we?)
Short meeting (15 min)
Tell the others if you need help.</p>
<h2 id="sprint-planning">Sprint planning</h2>
<p>Work together with the whole SCRUM team for sprints.
Look in the backlog.
Make a sprint backlog. (this can’t be changed from the outside)</p>
<h2 id="sprint-review">Sprint review</h2>
<p>Check development status.
Sprint review max 4 hours with sprints of 4 weeks.
The client participates along with the team.
Only talk about what has been done.
Dialogue, no presentation.
Update the backlog.</p>
<h2 id="sprint-retrospective">Sprint retrospective</h2>
<p>For increasing quality and effictivity.
What went well/bad?
How can this be improved for the future?</p>
<h2 id="roles">Roles</h2>
<h3 id="product-owner">Product owner</h3>
<p>Stakeholder contact
Updates/prioritises the product backlog
Can be a person dedicated to the client
The goal is the maximise product value
Can delegate but is responsible</p>
<h3 id="scrum-master">SCRUM master</h3>
<p>Ensure everyone is keeping in-line with SCRUM
Not the management leader
Ensure the team is effective
Deal with the teams blockages</p>
<h3 id="developers">Developers</h3>
<p>They own the backlog
Programmers, UI, UX and so on</p>
<h1 id="q6.-key-features-of-xp---extreme-programming">Q6. Key features of XP - eXtreme Programming</h1>
<h2 id="what-is-xp">What is XP?</h2>
<p>An agile, incremental development method with focus on:
- Collaboration
- Quick and early software creation
- Skillfull development practices
XP takes all the ‘good things’ the extreme. (testing, pair programming).</p>
<p>The customre should be available full time for the use of the XP team.
In XP, the customer is a member of the dev team and is responsible for bringing requirements.</p>
<p>Pair programming: developers work in pairs, checking each other’s work to ensure quality.</p>
<h2 id="qualities-of-xp-that-fit-to-scrum">Qualities of XP that fit to SCRUM</h2>
<p>Pair-programming.
Writing unittests before the code (with the help of TDD).
Partners often have to integrate their code (use continuous integration).
Refactor as often as possible.
Collective ownership of code.
Customer on-site, user stories, planning game, …</p>
<h3 id="what-does-xp-and-scrum-have-in-common">What does XP and SCRUM have in common?</h3>
<p>Work should be done incrementally/iteratively.
Teamwork, transparency, communication and prioritisation are crucial.
Requirements are broken down into bite-size pieces.
There is overlap with the roles. (XP client and SCRUM’s product owner)</p>
<h2 id="what-values-are-xp-based-on-according-to-larman">What values are XP based on according to Larman?</h2>
<p>Communication, simplicity, feedback, courage.</p>
<h3 id="communication">Communication</h3>
<p>Pair programming
Customer on-site
Acceptance test
Daily standup (short meetings)</p>
<h3 id="simplicity">Simplicity</h3>
<p>Teams implement exactly what was asked for. Nothing more.
Strive for simple designs and quality code.</p>
<h3 id="feedback">Feedback</h3>
<p>Early and frequent feedback is crucial.
Feedback can come from unittests, team members and the client.
Continuous integration.
Acceptance test that the client performs.
Short sprints.</p>
<h3 id="courage">Courage</h3>
<p>Developers should be honest.
Don’t make excuses for issuse.
Don’t be afraid to make big changes.</p>
<h2 id="how-is-xp-extreme">How is XP extreme?</h2>
<p>E.g. If tests are good, do them all the time.
Takes all good things, and places them at the core of the process.</p>
<h2 id="name-some-key-practices-in-xp">Name some key practices in XP?</h2>
<p>Unit test, pair review, customer on-site, continuous integration, testing, early test, unit test, TDD.</p>
<h2 id="what-is-a-user-story">What is a user story?</h2>
<p>Brief feature request, a promise for conversation.
Written on a card with criteria for confirmation on the back.</p>
<h2 id="story-maps---user-story-mapping">Story maps - User story mapping</h2>
<p>To see the bigger picture of the user stories.
To understand how things are now and to imagine how they could be.
Visualize the stories you tell about your software.</p>
<p>Story maps consist of:
* User
- a card that tells a story about a type of person, doing something to reach a goal.
* Activities
- Jobs done by similar people to reach a time
* Backbone
- Activies and jobs on a higher goal tier, give the user story structure.
- This is a big goal, that the little goals are attached to.
* User tasks
- Short, concise sentences that explain the goal.
* Sub-tasks
- Break down more complicated goals.
* Release slices
- Identify tasks. The smallest number of tasks that allow specific users to reach their goal.</p>
<p>Story map process has 4 levels</p>
<h2 id="what-is-the-format-a-user-story">What is the format a user story?</h2>
<p>“As a <user> I want <feature> so that <why>”.
Who, what, why.</p>
<h2 id="how-does-xp-describe-lifecycle-for-a-system">How does XP describe Lifecycle for a System?</h2>
<p>Exploration, planning, iterations to first release, productionizing, maintenance.</p>
<h2 id="what-is-the-iteration-called-in-xp">What is the iteration called in XP?</h2>
<p>Iteration</p>
<h1 id="q7.-product-planning-requirements-elicitation-product-vision-product-roadmap">Q7. Product Planning: Requirements Elicitation, Product Vision, Product Roadmap</h1>
<h2 id="what-main-requirement-activities-are-there">What main requirement activities are there?</h2>
<p>Elicitation and analysis of needs.
Specification of requirements.
Validation of requirements.</p>
<h2 id="elicitation-and-analysis-of-needs">Elicitation and analysis of needs</h2>
<p>There are two fundamental approaches to Requirement Elicitation:
1. Interview, where people talk about what they are doing.
2. Observation or etnography, where you observe how people do their work and which technologies they use and so on.</p>
<p>Use a mix of interview and observation to gather information.
This can be used to find the requirements that form the basis of further discussion.</p>
<h2 id="requirement-specification">Requirement specification</h2>
<p>Is a process in which you write down user and system requirements into a document.
Ideally, these requirements should be clear, consistent, complete and easy to understand.
User requirements should be written in natural language and supplemented with dialogue and tables in the document.
System requirements can also be written in natural language, but other notations, graphs, maths, etc can also be used. (state machines, automata)</p>
<h2 id="requirement-validation">Requirement validation</h2>
<p>Is the process of controlling of ensuring that the system requirements will are really what the client wants.
There are different checks that can be used to validate the requirements.</p>
<ol>
<li><p>Validity checks:
Check if the requirements reflect the users real needs.
User needs can change over time, so this is an important thing to keep track of.</p></li>
<li><p>Consistency checks:
Requirements should not conflict with others. </p></li>
<li><p>Completeness checks:
The requirement specification should be comprehensive for every function and the limits that the client wants.</p></li>
<li><p>Realism checks:
Using knowledge on existing systems, control the requirements to ensure that they fit within the budget and time-frame.</p></li>
<li><p>Verifiability:
You should be able to create tests that verify whether or not a requirement is met.</p></li>
</ol>
<h2 id="requirement-validation-techniques">Requirement validation techniques</h2>
<ol>
<li><p>Requirement reviews
Requirements are analyzed systematically by a team of judges, to check for mistakes or conflicts.</p></li>
<li><p>Prototyping
Develop executable models of the system and verify with the client that it meets their expectations.</p></li>
<li><p>Test-case generation
Tests can be designed along with requirements instead of after the fact.
If it is difficult to design tests for a requirement, that can mean the requirement is unrealistic.</p></li>
</ol>
<h2 id="what-are-the-steps-in-elicitation">What are the steps in elicitation?</h2>
<ol>
<li><p>Discovery & Classification
This is the process of interacting with the stakeholders to find their requirements.</p></li>
<li><p>Categorization
Take the unstructured list of requirements and group related requirements together.</p></li>
<li><p>Prioritization & Negotiation
Conflicts can arise when there are multiple stakeholders.
Prioritize the most important requirements, through negotiation, discussions, compromises and meetings.</p></li>
<li><p>Documentation
Here the requirements are documented.</p></li>
</ol>
<h2 id="why-is-it-difficult-to-elicit-requirements">Why is it difficult to elicit requirements?</h2>
<p>Many stakeholders with conflicting needs.
Stakeholders speak their own “language”.
Lack of communication because things are assumed to be “obvious”.</p>
<h2 id="what-is-a-recognized-way-to-communicate-requirements">What is a recognized way to communicate requirements?</h2>
<p>Stories, Scenarios.</p>
<h2 id="how-are-requirements-documented-in-waterfall-and-in-scrum-in-product-planning">How are requirements documented in Waterfall and in SCRUM, in Product Planning?</h2>
<p>Waterfall: Verify the requirement specificatino with strict change management.
SCRUM: Product vision and product backlog, are discussed and updated every sprint.
Product Planning: Product vision, release plans and/or product roadmaps.
XP: User Stories.</p>
<h2 id="how-are-requirements-negotiated-with-stakeholders-in-waterfall-and-scrum">How are requirements negotiated with stakeholders in Waterfall and SCRUM?</h2>
<p>Waterfall: Be up front in the requirements phase - state it now or it will be difficult later on.
SCRUM: Ongoing refinement of product backlog with stakeholders, say what is most important now, we will continue.
XP: Customer on-site.</p>
<h1 id="q8.-product-refinement-and-forecasting-user-story-mapping-personas-stakeholders-product-backlog">Q8. Product Refinement and Forecasting: User story mapping, personas, stakeholders, product backlog</h1>
<h2 id="what-is-a-persona">What is a persona?</h2>
<p>User personas are a useful technique to describe users of your product.
A fictional character with a name, picture, relevant characteristics, behavior, opinions and a goal.
Different people can have different goals.
Understand a personas goal is useful for creating a product that is meaningful to the users.</p>
<h2 id="what-is-a-user-story-1">What is a user story?</h2>
<p>Short description on a type of user, a goal and a reason.</p>
<h2 id="where-do-we-use-the-terms-product-feature-epic-user-story">Where do we use the terms: Product Feature, Epic, User story?</h2>
<p>Product Feature: Corresponds to an Epic.
Epic: A collection of related user stories.
User story: Breakdown of an Epic. </p>
<h2 id="what-is-a-user-journey">What is a user journey?</h2>
<p>The experiences a person has, when interacting with the software.</p>
<h2 id="what-are-the-key-characteristics-of-a-product-backlog">What are the key characteristics of a product backlog?</h2>
<p>This is to do list of items a SCRUM team must tackle.
- Software requirements.
- User stories.
- Descriptions of supplementary tasks that are needed, such as architecture definition or user documentation.</p>
<h1 id="q9.-risk-management">Q9. Risk Management</h1>
<p>A risk is a potential problem.
The possibility of loss or damage.
Risk Management: project leaders must evaluate the risks that can affect a project, monitor them, and handle them when problems arrise.</p>
<h2 id="example-of-risk-categories">Example of risk categories</h2>
<ol>
<li>Uncertainty, project, technical, business.</li>
<li>Keyperson from team dies, a supplier is not delivering as promissed.</li>
</ol>
<h2 id="categories-of-risk">Categories of risk</h2>
<h3 id="project-risks">Project risks</h3>
<p>Risks that threaten the project plan.
Time will be wasted and costs will rise.</p>
<h3 id="technical-risks">Technical risks</h3>
<p>Architectural design.
Arrises because problems can be harder to solve than expected.
Vagueness in the specification.
Project gets older and starts to decay.</p>
<h3 id="business-risks">Business risks</h3>
<p>Market risk. What if no one uses the product?
Strategic risk. We don’t need that new component after all.
Sales risk. How the fuck do we sell this?!
Management risk. The top management don’t support the project anymore.
Budget risks. Budget or personnel is lost.</p>
<h2 id="how-do-you-do-risk-analysis">How do you do risk analysis?</h2>
<p>Risk analysis and management are actions, that help a software team understand and handle uncertainty.
It is a good idea to identify risks.
Evaluate the probability of risks.
Estimate the impact of a risk and form a reaction plan for if the risk actually happens.</p>
<h2 id="identify-risks-and-calculate-risk-exposure-and-describe-consequence.">Identify risks and calculate risk exposure and describe consequence.</h2>
<p>Risk exposure = probability * loss, describe consequence.
Probability < 100%. If p = 100% then it’s an issue.</p>
<p>Prioritize according to risk exposure, establish cut-line.
Deal with the risks above the line, accept the ones below.</p>
<p>Establish for each risk above the cut-line (RMMM: Risk Mitigation, monitor, management)</p>
<h3 id="mitigate">Mitigate</h3>
<p>We want to prevent the risk from becoming an issue.
We can reduce the probability.
Or try to reduce the associated loss.
Risk exposure = probability * loss.</p>
<h3 id="manage">Manage</h3>
<p>For when a risk has become a loss, try to minimize the loss.
This assumes the mitigation activity was unsuccessful.
This is done by the project leader.</p>
<h3 id="monitor">Monitor</h3>
<p>Observe how risks change over time.
How the probabilities, loss, or the environment, change over time.</p>
<h2 id="how-are-risk-management-part-of-project-management">How are risk management part of project management</h2>
<h3 id="waterfall-plan-driven">Waterfall / plan-driven</h3>
<p>Risk and risk plans are part of the plans in project management.
Development of others plans to contribute to identification of risk.
It is planned.</p>
<h3 id="agile---inspect-and-adapt-is-reduction-to-produce-the-right-product">Agile - inspect and adapt is reduction to produce the right product</h3>
<p>Daily SCRUM: Do you have any impediments?
Sprint review: Inspects risk related to product and stakeholder.
Sprint retrospective: Adresses risks related to how the team works.</p>
<h2 id="what-are-bhms-primary-risks">What are Böhms primary risks?</h2>
<p>Personal shortcomings, unrealistic schedule, wrong function…</p>
<h1 id="q10.-how-is-quality-defined">Q10. How is quality defined?</h1>
<h2 id="software-quality-attributes">Software quality attributes</h2>
<h3 id="nonfunctional-requirements">Nonfunctional requirements</h3>
<p>Safety, security, reliability, complexity, adaptability, testability, understandability, efficiency, usability, etc…</p>
<h3 id="functional-requirements">Functional requirements</h3>
<ul>
<li>Requirement Specification (waterfall)</li>
<li>Product backlog and User Stories (agile)</li>
</ul>
<h2 id="what-is-quality">What is quality?</h2>
<p>Quality is evaluated aesthetically, symbolically and functionally
Quality can be either objective or subjective.
Quality may not always be obvious.</p>
<h2 id="definition-of-quality">Definition of quality</h2>
<p>Quality is a reflection of one or more peoples evaluation of the compliance of a product or service with their expectations.
Quality can be broken into three types of categories:
1. Product quality.
2. Process quality.
3. Quality of expectations.</p>
<p>Quality tradeoffs are unavoidable.
Quality consists of:
- Quality assurance: plan or design processes to prevent bad quality.
- Quality control: track that work products meet quality standards.</p>
<h2 id="why-invest-or-pay-for-quality-management">Why invest or pay for Quality Management?</h2>
<p>Cost of not doing it is bad quality - fixing errors.</p>
<p>Direct cost of error correction:
- Loss. (effort)
- Wasted work. (for users of the program)
- Maintenance usually has larger costs than development.</p>
<p>Indirect cost of error correction
- Follows from poor quality (unsatisfied users)
- Has potentially severe consequences (losing customers)</p>
<p>Quality Management reduces these costs significantly.</p>
<h2 id="validation-fit-for-use">Validation (fit for use)</h2>
<p>Are we building a system that is fit for use?
Compliance with the users expectations and experiences?</p>
<h2 id="verification-requirement-specification-being-met">Verification (requirement specification being met)</h2>
<p>Do we pass all tests and requirements?
Are we building a system with all the requirements implemented?
Unit/integration tests</p>
<h2 id="techniques-for-verification-and-validation">Techniques for verification and validation</h2>
<p>Testing: of programmes and prototypes.
Review: of specifications, documentation and programs.</p>
<h2 id="is-it-verification-or-validation">Is it verification or validation?</h2>
<p>A user must participate in order to validate.
Verification focuses on the compliance to the specifications and a client usually doensn’t participate.</p>
<h2 id="v-model">V-model</h2>
<h1 id="q11.-test-and-review">Q11. Test and review</h1>
<p>Tests are a set of practices that support verification and validation.
The purpose is to ensure a program does what it is supposed to, and to discover errors before delivery.
This is done by making sure the progrm meets the requirements and by finding incorrect or undesirable behaviour.
Verification: Unit test, component test.
Validation: prototype test, user acceptance test.</p>
<h2 id="what-is-peer-review">What is peer review?</h2>
<p>Evaluation of work of one or more people with similar skills (peers).
Mostly in the form of documents but can also be analysis of code.</p>
<h2 id="what-is-the-difference-between-review-and-test">What is the difference between review and test?</h2>
<p>Review is static, and there is no interaction between errors found in review.
Tests are dynamic and errors can come as side-affects of an initial errors.
Reviews (inspections) and tests are complementary to quality techniques.
Both should be used under the verification and validation process.
Inspections can control compliance with a specifications but not with the clients or users actual requirements.
(Unless the user participates in the review. Prototypes are preferred for user participation)
Inspecions cannot control non-functional properties such as performance, usability, etc.</p>
<h2 id="when-is-review-good">When is review good?</h2>
<p>For documents, designs, architectures, plans, etc.</p>
<h2 id="when-is-test-good">When is test good?</h2>
<p>For functionality and dynamic use of the program.</p>
<h2 id="what-is-the-v-model">What is the V-Model</h2>
<p>A model that shows the connection between tests at different levels and primary activities that drive the tests.</p>
<h2 id="name-tests-at-different-levels">Name tests at different levels:</h2>
<p>Unit test, component test, integration test, system test, user acceptance test.</p>
<p>Unit test: confirm valid and invalid input.
Integration test: confirm that interfaces are compatible and work as expected.
Acceptance test: validate fit for use, exploratory test.</p>
<h2 id="when-is-test-done">When is test done?</h2>
<p>Plan driven: in the end (often a dedicated test-team aspart of QA)
Agile: all the time (test competence on the team, accept criteria on story, automated test, TDD)</p>
<h1 id="q12.-configuration-management-and-devops">Q12. Configuration Management and DevOps</h1>
<h2 id="what-is-devops-how-can-you-define-it">What is DevOps, how can you define it?</h2>
<p>DevOps is a method for both development and operation.
DevOps is a development method for IT systems that connects different activities in projects.
DevOps is a culture, that focuses on the entire software productions life cycle.
The goal is to remove barriers between development and operation teams, to be able to react quickly to the users needs.
It is also defined by The Three Ways:
1. Flow.
2. Feedback.
3. Continuous Learning.</p>
<h2 id="what-is-the-purpose-of-continuous-integration">What is the purpose of Continuous Integration?</h2>
<p>When the code is checked, it is automatically integrated with the system.
Speed up the rate of delivery and run tests constantly.
Bsed on tools to automate the process.
Depends on a suite of unit tests.
Does NOT eliminate the need for testers.</p>
<h2 id="what-is-the-purpose-of-continuous-testing">What is the purpose of Continuous Testing?</h2>
<p>Continuous Testing in DevOps is a type of software test that involves testing at all stages of a develoments lifecycle.
The goal is the continuously evaluate the quality of the software.</p>
<h2 id="what-is-the-purpose-of-continuous-delivery-and-deployment">What is the purpose of Continuous Delivery and Deployment?</h2>
<h3 id="continuous-delivery">Continuous Delivery</h3>
<p>Ensure that code can be implemented securely.
Ensure that the business and service application function as expected and deliver every change to production.</p>
<h3 id="continous-deployment">Continous Deployment</h3>
<p>Ensure that tests are automated and that every change is automatically implemented in production.
Makes the development and release process faster and more robust.</p>
<p>Automated access to well defined environments.
Tools like Docker for containerization or Virtual Machines.</p>
<footer>
<a href="/" class="homepage-link">adast.xyz</a>
—
<a href="https://git.adast.xyz/explore/repos">Gitea</a>
•
<a href="https://github.com/adastx">Github</a>
•
<a href="https://odysee.com/@adamski:f">Odysee</a>
•
<a href="https://youtube.com/c/adamski1">Youtube</a>
•
<a href="https://www.twitch.tv/adastx">Twitch</a>
•
<a href="https://steamcommunity.com/id/adastx">Steam</a>
</footer>
</body>
</html>
|
