Please enable JavaScript.
Coggle requires JavaScript to display documents.
350: software engineering: requirements, spcifications, design, validation…
350: software engineering: requirements, spcifications, design, validation
Structural Architecture of a Development Project
(4 styles)
at minimum:
A project has one or more sub-projects, always at least one subproject
as opposed to
multiple independent small projects
4 advantages
can be built with a single command
share certain configuration data
more tightly coupled
whole project is stored in a single location/repository,
sub-project
the code and data that yields a single deliverable
deliverable
3 examples
an executable program, a library[Java .jar or
C/C++ .a, .lib, .so, or .dll] , or
a reference manual)
usually an archive of some kind
mainly "binary" deliverables
in java
2 more items...
if its a server-side web application
1 more item...
if its an android app
1 more item...
Sub-Project Directory (Java)
contains 4 things
sub-project build & configuration
source code directory
project and test data
target directory for deliverables and other build projects(source code output placed here instead of source code directory when compiled)
Project Directory
contains 4 things
Top-level project documentation.
ex:
README.md, LICENSE.md
Overall project build & configuration information
ex
build.xml
does what?
1 more item...
bin
lib
contain
1 more item...
One sub-directory per sub-project
ex
algae-client-server
algae-cppserver
algae-reference-manual
demos
Version control and configuration management information
ex:
.git, .gitignore, ivysettings.xml
Apache
apache vs android/gradle
gradle uses the android structure by default for java projects,
AnGrad products of build are stored in build/,
Apache products of build are stored in target/
AnGrad build/ has a more detailed breakdown compared to target/
build (angrad) vs target(apache)
java vs c/c++ file structures
c/c++ can be more flexibile
why
java's file structure must reflect the program structure
src
main
java
java source code,
compiled code goes to target/classes
resources
data files that will be included in the deliverable archive
data
data files required during build but not part of deliverable
test
java
java source code,
compiled code goes to test-classes
resources
data files, available during testing via CLASSPATH
copy contents of this
folder into target/test-classes
to make test resources available during testing through the code written for accessing main(deliverable) resources
data
test data
identical layout in both
apache and angrad
target
classes
data and compiled code packed into the .jar deliverable
project.jar
the deliverable
test-classes
data and compiled source code from test/java for unit testing
reports
optional, method of storing testing outputs/reports
Android/Gradle
src
main
java
resources
data
test
data
resources
java
build
classes
main
compiled code
test
compiled code
libs
deliverables placed here
reports
generated reports inlcuding documentation, test coverage, analysis, etc
test-results
outputs from testing
tmp
work area for general temporary files
c/c++ subproject
include
src
compilation units
.c or .cpp files
bin
executables, object files produced by compiling src/
sometimes librariaes and executables are copied to the project-level bin and lib directories
lib
obj
optional, exclusively for .o files
Software development process models
2 types
structured
3 kinds
waterfall
RADIUTVVOM
design
implementation
unit testing
verification & validation
VER = PR
are we building the product right?
does it work as intended as outlined in the specification?
VAL = RP
are we building the right product?
does it do what the customer wants it to do?
two forms
testing
definition
1 more item...
4 steps
5 more items...
5 stages
5 more items...
basic process
1 more item...
non-testing
V&V
two subtypes
2 more items...
definition
anything meant to check if a system meets a users' needs by searching for defects and judging if it is usable in an operational situation
this stage is technically also done during 2 other phases
operation & maintenance
user stories
3 qualites of a good user stories
customer-centric
customer's POV
2 more items...
written by the customer or ranked by priority by the customer/dev team
1 more item...
validatable
clear criterion for completion
1 more item...
can be demonstrated to the customer
represented as
1 more item...
estimatable
meaning
1 more item...
represented as
1 more item...
are
1-2 sentences describing a requirement
used in
used for
organizing and tracking work during iterative development
as many as time for that increment
allows for those stories to be implemented,
enough to be visible
2 more items...
5.0 units of effort per 1 incremement
grouped on
1 more item...
iterative meaning we can
revisit them in later
iterations
1 more item...
incremental requirements elicitation and analysis
4 things added incrementally as work goes on:
estimated effort to implement functionality
4 cases when the estimate shuold be >1.0
4 more items...
priority (how important it is to end users)
splitting (stories too big[epics] to fit into one pass/increment of the process or to estimate)
merging (stories too detailed to be implemented during a separate pass/increment)
non-functional stories
are differentiated from regular stories by 2 things
getting done late in development or working on an already 'finished' system
describe improvements or new functionalities for an existing system
ex:
performance requirements, scalability, portability
are not\
the same as the requirements
3 kinds of Special Stories
Documentation stories - usually just implied as part of a regular story unless its a special case
Bug Stories - fixes for bugs that passed unit testing, hard to estimate so allocate fixed time then schedule a follow up
Spike Stories - lack of info to estimate a story,
ex
1 more item...
requirements analysis
agile
aka
extreme
uses 2 things
TDD
test-driven development
definition
drivers that feed input to the test code and then judge their response
in TDD, first thing to do when
a bug is reported/new feature requested
add new tests that fail because of the bug/missing feature, allowing us to know we fixed the problem when the test is passed,
TDD is a stronger form of
test-first development
3 more items...
is a
repeated cycle of 3 steps
3 more items...
5 advantages
of TFD and TDD
tests written while "fresh" > tests written when worn out after writing the code
boundary and special value tests clarify the software design, reduces # of eventual faults actually introduced
encourages designing for testability by making sure the interface provides the "hooks" you need to do testing
tests serve as examples of how the unit's interface is used, valuable as documentation, helps us identify when interface may not have parameters to supply data, wrong parameters, functions that would manipulate the ADT state or examine the ADT state to see effects of manipulation
trying to write black-box tests is a form of validation of the interface design
3 rules
You are not allowed to write any production code unless it is to make a failing unit test pass.
You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
3 advantages of the rules
1 more item...
2 way TDD division of a story into tasks
Implement the story. (includes unit testing)
Integrate and commit changes.
continuous integration
definitio
when work is done on a unit, its tests are rune, and the changed are automatically integrated into the whole system, then system and integration tests are rerun
3-step process
write tests,
then code
rerun tests
every time units
are added/changed
aka
TDD & continuous integration
spiral
iterative & incremental
I&I vs structured models
could lead you to getting trapped in a local optimum
implementation alongside each stage,
as opposed to ADIV
definition
a process describing how work is to be done
workflow
TOI
whatever is currently being worked on
ex:
a system
a single unit
daily work of a software developer
ADIV
Analysis
design
implementation
validation
expected outputs