1. Praktikum -- Software Engineering
COMMENTED VERSION
Lecturer: Prof. Oscar Nierstrasz
Office: Schützenmattstr. 14/103
Tel. 631.4618
Email: oscar@iam.unibe.ch
Secretary: Frau I. Huber, Tel. 631.4692
Assistants: Markus Lumpe, Marc Heissenbüttel, Thomas Hofmann
WWW: http://www.iam.unibe.ch/~scg
Overview
-
Goals of this workshop
-
Project overview
-
Schedule: milestones, deliverables
-
Analysis and Design documents: guidelines
-
Prototyping: requirements validation and iterative development
-
Testing: coverage and regression tests
-
Teamwork: roles and responsibilities
-
Tools: UML, rcs, make, SNiFF+, ...
Goals of this Workshop ...
Methodological skills
-
Practising Requirements Collection and Specification
-
Practising Responsibility-Driven Design
-
Evaluating Implementation Strategies
-
Prototyping
Practical skills
-
Working with incomplete requirements
-
Developing a complete product
-
Teamwork
Technical skills
-
Using UML
-
Programming with Java
-
Testing
Project Overview
Programme Committee Support System
-
Submission of papers by authors
-
Bidding for papers to review
-
Distribution and submission of review forms
-
Conflict detection and report generation
-
Keeping track of accepted/rejected papers
-
Access rights
Wish list
-
Both WWW and email support
-
Java as implementation language of choice (alternatives?)
-
Adaptable to different review forms and review procedures
More details to follow ...
Project Characteristics
Several characteristics of "real" projects:
-
Open, changing requirements
-
Existing procedures in place
-
Distributed, multi-platform
-
New technology, methods imposed
-
Ideal choice of implementation platform unclear
Non-issues:
-
No legacy data or software
-
No integration with existing applications
Schedule
|
|
Meeting
|
Homework/Consultation
|
|
1) 25.03.98
|
Introduction; form teams
|
Prepare interview questions
|
|
2) 01.04.98
|
Requirements interview;
introduction to Java
|
Specify requirements; prepare presentation; start prototyping ...
|
|
3) 08.04.98
|
Deliver and present initial requirements spec; feedback
|
Revise requirements spec; specify coarse design (architecture)
|
|
4) 15.04.98
|
Deliver design documents and revised requirements; exchange designs with other teams
|
Prepare design review (of competing design); start prototyping UI
|
|
5) 22.04.98
|
Design review; feedback
|
Revise coarse design; prepare detailed design
|
|
6) 29.04.98
|
Deliver detailed design spec; ...
|
Prototype UI; design test cases; schedule lab sessions
|
|
7) 06.05.98
|
Validate UI and test cases;
trouble-shooting (lab)
|
Implementation
|
|
8) 13.05.98
|
Validate UI and test cases;
trouble-shooting (lab)
|
Implementation
|
|
9) 20.05.98
|
|
|
|
10) 27.05.98
|
|
|
|
11) 03.06.98
|
|
|
|
12) 10.06.98
|
Deliver final application (source) and documentation (including final A&D docs)
|
|
|
13) 17.06.98
|
Feedback and Testat
|
|
|
14) 24.06.98
|
|
|
Analysis and Design
Requirements Specification
-
Describe what is required, not how it will be implemented --
don't confuse requirements specification and design!
-
Formalize scenarios, domain objects, functional and non-functional requirements
-
Use UML to formalize your models; use text to explain them
-
Specify enough detail so that someone else could design a solution
-
Keep specification up-to-date as requirements are refined
Design
-
Apply responsibility-driven design
-
Evaluate technical alternatives and document design decisions
-
Keep it simple; add complexity only when necessary
-
Anticipate changing requirements
-
Identify and factor out reusable components
Prototyping
Prototyping is an essential activity carried out during all phases of the software process.
Requirements validation
-
Prototype a user interface as early as possible to validate your requirements specification.
Evaluating design decisions
-
Prototype parts of your design to evaluate feasibility and usability of technical alternatives.
Iterative development
-
Integrate parts as early as possible to always have a running prototype of the target application that can be tested and demoed.
Testing
Coverage
-
Design tests that will exercise all required/implemented functionality
-
Check that all possible execution paths are tested
-
Apply both black-box and white-box testing
Regression
-
Automate testing so that all tests can be carried out after any system change
-
Set up tests so they can run in either
-
"verbose" mode (i.e., logging every interesting event), or in
-
"silent" mode (i.e., only reporting when and where tests have failed)
Responsibilities
Guidelines
-
Each team member should assume a set of well-defined responsibilities
-
but the work should be distributed amongst team members
-
Assign responsibilities according to the skills of your team members
Sample responsibilities
-
Project Administrator
-
Chief programmer/architect
-
Backup programmer
-
Tester/test case developer
-
Toolsmith
-
Component librarian
-
Documentation editor
Supporting roles
Client
-
answer questions about requirements
+
email log
-
accept/reject requirements specs
-
evaluate prototypes, final system
System support
-
system administration
-
maintain installation of required software
-
(limited) help for technical problems
+
email log
Consultants
-
meet regularly (minimum weekly) with their teams
-
oversee quality of work
-
give advice concerning software process, technical solutions etc.
-
crisis detection; trouble-shooting
Responsibilities may shift between these roles ...
Forming Teams
Identify your skills: strong and weak points
-
What skills would complement your own?
Round table: 20 seconds to present yourself
-
What do you have to offer; who are you looking for?
Form teams of five: look for suitable partners
-
Seek complementary skills that cover responsibilities
Prepare your strategy and tactics:
-
What questions do you need to ask of the client?
-
What interactions do you anticipate with other teams?
Tools
Use (at least) the following tools!
UML
|
Use UML to document all your models (esp. requirements specification and design).
|
SNiFF+
|
SNiFF+ integrates software development tools (compilers, version management etc.) and provides support for development of software in teams.
|
rcs
|
Use version control for all text documents (i.e., both source code and documentation).
|
make
|
Use make to automate compilation, installation, testing and cleanup.
|
javadoc
|
Automate generation of HTML documentation from source code.
|
Many other tools are available -- use them!
If you aren't sure what tool you should use to get a job done, just ask!
Special tools can be installed, if necessary ...
Component Development
Consider developing components wherever you identify a generally useful abstraction.
-
Well-design components will be easier to adapt and reuse when the application evolves.
-
A component may be either a piece of software (class, package) of a final application or a specialized tool to help in the development or testing of the application.
Consider marketing components to other teams:
-
A team can deliver a (substantial) component set instead of a complete project if it finds at least two other client teams (subject to approval of the course instructors!)
-
A component provider must supply (according to contract):
-
complete software with documentation
-
test drivers
-
maintenance support