a software process model is a simplified representation of a software process, presented from a soecific persepctive.
examples of process persepctive:
** by reducing dependicies in project, you reduce the
The less new code you write the better, the more old code you use is the better. if you write less new code, you’ve written less new bugs. the less code is mofiied and the more you reuse code the likely it is that the costs are going to come down.
costs vary depending on type of system cost of validation and testing is very high for a nuclear software system. something like saftey critical systems, usualy there is a team of external programmers to double check. sometimes they do the same system twice independently and then the 2 match in their output to test them against eachother.
Distribution of costs depends on the development model.
any good software enginner uses a lot of tools. bug management tools, IDEs, GIT (version control systems)
good software is a lot different than good other things. good software has to be idealy easy to understand and read. if its hard to understand itsn ot good software.
good variable names
as a software engineer you have a response to be honest and ethical if you are to be respected as a professional. this goes beyond what you need to do in law. morals, you know?
functional and non functional requirements are equally important. Software must be written in java is a non functional requirement. if the user doesnt see it, it’s a non functional requireement.
functional modelling of requirements show the external view of the system
use cases are a scenario based technique in the unified modelling language (UML) which identity the actors in an interaction and which describe the interaction itself.
in a use-case diagram, an actor is a user of the system acting in a particular role. it can be a non human, it can be a person or it can be an external service that the system uses.
we have includes stuff. so if a customer wants to view balance, we want to authenticate the user. so we say that the action “view balance” (use case) includes the authenticate user action. the authenticate user action can extend into “re-enter pin” or “reject transaction” if they get their pin wrong many times.
the smaller the pieces they are, the easier theya re to understand and test. we want to break this down as much as possible.
THE ARROWS POINT TO THE ONE EITHER BEING EXTENDED OR BEING INCLUDED
once you get a hang of it, a customer can usualyl understand it. if you have a lot of incliudes / extends that can make the diargam mroe confusing. only use them if its absolutel neccesary. generally i dont use an include unless something is included by one other use case. same thing with extends.
You don’t put a drywall up before you put the wiring in.
We can think of a series of activities as a process. A process is a series of activities. We’re going to have a look at some software dev process activities.
not like building a brdge, can be changed at any time. software is complete mutable.
user gets used to software working one way and you change it, this hurts the user. making a change and the user expeirence changes, you have to help the user out. one way its done is by allowing you switch to a classical / old view. they say “do you want to use the new interface or stick with the old interface”.
going from specification, design and implementation
we want to log high volume transactions, standard logs (logins / logouts), failed logins log, alert logs (failed logins for top level clearance users)
all items are given security clearance level:
a subject cannot read a document above their clearance level no write down - a document cannot be copied or included with another document with a lower security clearance so if i want to add a top secret to a sensitive document the result will be a top secret document. if you are a level 2, you cannot make a level 1 document.
dont use a normal shredder, use a cross shredder.
validy - does the system provide the functions which suppor tthe customers needs consistency completeness realism - can it be implemented given the available budget. requirements checkable - if the system had to run fast at all times.
we’ve defined this card payment system and if you do this, this will happen.
if we have a requirement “must return X within 30 seconds when 500,000 users are online”, is the easiest way to test this to rent out a seperate server, create 500,000 users and get them all to use the system?
abstract descrptions of systems whose requirements are being analysed
context models are used to illustrate the boundarieds of a system. social and organisational concerns may affect the decision on where to position system boundaries.