Experimental evaluation in computer science: a quantitative study
Journal of Systems and Software
Software metrics (2nd ed.): a rigorous and practical approach
Software metrics (2nd ed.): a rigorous and practical approach
The quality approach: is it delivering?
Communications of the ACM
Software architecture in practice
Software architecture in practice
Evaluating software architectures: methods and case studies
Evaluating software architectures: methods and case studies
Guide to the Software Engineering Body of Knowledge - SWEBOK
Guide to the Software Engineering Body of Knowledge - SWEBOK
Editors' introduction: Comparative software engineering: Review and perspectives
Annals of Software Engineering
Preliminary guidelines for empirical research in software engineering
IEEE Transactions on Software Engineering
Software Product Quality Practices Quality Measurement and Evaluation using TL9000 and ISO/IEC 9126
STEP '02 Proceedings of the 10th International Workshop on Software Technology and Engineering Practice
IEEE-CS/ACM computing curricula: software engineering volume
Proceedings of the 8th annual conference on Innovation and technology in computer science education
| Hi-index | 0.00 |
SWEBOK describes what knowledge a software engineer who has a Bachelor's degree andfour years of experience should have. SEEKdescribes the knowledge to be taught in an undergraduate program in software engineering.Although different in scope and purpose, thereare many similarities between the two, and after all, even experienced developers need an ed-ucation, don't they? A full-day workshop onthe alignment between SWEBOK and SEEK,held at STEP 2002, revealed a number of issues that received either a scant or a scattered treatment in either or both documents.These issues include:software architecture,software measurement,and software quality.In addition, topics of debate were whether ornot user interface design should be consideredpart of software design, or rather deserves itsown, separate treatment; and whether maintenance/evolution merits a separate discussion,or should rather be seen as the default mode ofoperation in software development. This paperelaborates the discussions of this workshop.