PSD3/REM Quality Assurance and Standards [email protected]M o n 1 2 N o v 2 0 1 2 Think about: 1. Which is more important: product quality or process quality? P' 2. Look at the Capability Maturity Model. At which level would you characterize the following processes in your team: a. Version control (of source code, documents, etc) H b. Risk management (detection, mitigation, etc) Ij. c. Task scheduling and prioritization | 3. Give one advantage and one disadvantage of standardizing a programming language, e.g. ISO C99. ' / 4. What kinds of measurements might you take to measure quality of these software engineering processes? a. Code development b. Unit Testing The Capability Maturity Model is a framework for improving software engineering processes. us on process provement 'rocesses measured d controlled Process^^naracterized for the fganization and Is proactive. ijects tailor their processes from panizaiion's stanttards) 'recesses characterized for projects id is often reactive. ^Processes unpredictable, Driy controlled and reactive
Transcript
P S D 3 / R E M
Quality Assurance and StandardsJ e r e m v . S i n q e r @ q l a s q o w . a c . u kM o n 1 2 N o v 2 0 1 2
T h i n k a b o u t :
1. Which is more important: product quality or process quality?P'
2. Look at the Capability Maturity Model. At which level wouldyou characterize the following processes in your team:
a. Version control (of source code, documents, etc) Hb. Risk management (detection, mitigation, etc) Ij.c . Task schedu l i ng and p r io r i t i za t i on |
3. Give one advantage and one disadvantage of standardizing ap r o g r a m m i n g l a n g u a g e , e . g . I S O C 9 9 . ' /
4. What kinds of measurements might you take to measurequality of these software engineering processes?
a. Code developmentb. Unit Testing
The Capability Maturity Model is a framework for improving softwareengineering processes.
us on process
provement
' r o c e s s e s m e a s u r e dd con t ro l l ed
Process^^naracterized for thefganization and Is proactive.
ijects tailor their processes frompanizaiion's stanttards)
'recesses characterized for projectsid is of ten react ive.
^Processes unpredictable,Driy controlled and reactive
4̂ Quality Assurance is "the process of defining how software qualitycan be achieved and how the development organisation knows thatthe software has the required level of quality."
» Quality Assurance - framework of procedures and standards» Quality Plan - selection and adaptation of procedures and
standards for a project» Quality Control - carrying out processes that ensure procedures
and s tandards a re fo l l owed
A standard is a document approved by a recognized body, thatprovides, for common and repeated use, rules, guidelines, orcharacteristics for products, processes or services with whichcompliance is not mandatory.
[A Guide to Project Management Body of Knowledge
; i t , u ,
Loah.̂ V̂ pii) 1"̂ (rtN G./l~
Inspection Issue Log
ProjccI:Inspection ID: _Mcclinc Date: _R e c o r d e r :
Requirements Engineering MGroup Exercise 1 (D1-D5): Internship Management System
Tim Storer and Rose English
Revision 3250, made 19/09/2012 by tws
The aim of the Requirements Engineering M (REM) group exercise in the first semester is togather and validate requirements to rfiake sure that we design and build a system in the secondsemester tha t meets the needs o f c l ien ts and o ther s takeho lders .
At the end of this group exercise, you will be able to:
• organise a project group;
• schedule and plan project resources;
• carry out requirements capture and specification;
• carry out quality assurance reviews on some of the group exercise activities and deliverables;a n d
• produce documentation of project organisation, requirements and evaluation.
Each group must identify, specify and evaluate the requirements for the system described inSection 1. The topic of the exercise has been chosen so that the context of use of the system willbe reasonably familiar to both students and staff and so that realistic stakeholders will be easy tofind and involve in the requirements gathering process.
This project will be the first piece of work you have done in the School of Computing Sciencethat requires serious coordination of your efforts with those of other students. Successful projectmanagement, therefore, will be an important aspect of the exercise.
1 I n i t i a l P r o b l e m D e fi n i t i o n
Software Engineering (SE) and Electronic and Software Engineering (ESE) students in the Schoolof Computing Science are required to complete an internship as part of their course, in the summerbetween level 3 and level 4. An internship is a short period of time that a student spends workingwithin in a company in order to gain experience (from as little as a month up to a year). InternshipsIn the software industry are normally paid, although the rate offered can vary from company tocompany. The School imposes requirements on these internships to ensure that the student receivesan appropriate experience for their degree programme. More details of these restrictions can be foundon the Software Engineering Summer Placement (SESP) moodle page.
Currently, available internships are advertised to students on an ad-hoc basis through the SESPmoodle page. An organisation wishing to recruit an intern submits an advertisement to the coursecoordinator, who publishes it on the course mailing list. The format and content of the advert canvary widely, including information about the nature of the internship (what the successful applicantwill do), duration, expected start date, compensation, person requirements and so on. The coursecoordinator checks each advert and comments on whether it is suitable for SE/ESE students, asstudents who are not enrolled on the SE/ESE scheme may also view the advertisements posted onthe SESP moodle page in order to obtain information about possible internships.
Sometimes internships applications are managed through the Careers Service's Club21 website;sometimes through the e-Placements scheme; and sometimes the company has its own system of
1
collecting applications. In addition, some advertisements are posted by academics in the school forstudents to work with them during the summer vacation.
The allocation of SE/ESE students to internships is tracked by the course coordinator separately,using a Microsoft Access Database. Students are required to inform the coordinator when they havesecured a placement, which may or may not have been advertised on the SESP page. The coordinatormust then approve the internship if it is suitable for the student s course.
The SESP course coordinator has decided that a unified system is necessary for collecting andpublishing internship advertisements, and for tracking which SE/ESE students have been successfulin securing them. An initial requirements analysis has found that the following features must besupported by the system:
• Submission of internship advertisements
• Review, comment and publication of internship advertisements by the course coordinator• Review of advertisements by students
• Notification of successful selection for an internship by an SE/ESE student
More details of these and other features will need to be discovered during detailed requirementsanalysis.
1 . 1 C o n s t r a i n t s
The clients believe that other useful system features could be identified after a more extensive andcareful analysis of the problem domain. However, the clients are also aware that there are seriousconstraints on resources for analysis, design and. especially, implementation, so that the level ofsophistication of the system developed may have to be limited to stay within available resources.Therefore, the clients have agreed on the following constraints:
1. Assume that the maximum effort available for the design and implementation of this systemis the capacity of a REM Team. Constraints 2 and 3 are added in order to help maintain thisfirst constraint.
2. The system shall only be used within the School of Computing Science for advertising andmanaging internships for the software industry.
3. The system need only handle textual data (no graphics or multimedia elements) or graphics-and media-free HTML (e.g., this exercise sheet is an example of an acceptable format). Thisis not an HCI design exercise and additional credit will not be given for sophisticated userinterfaces. You should concentrate on the functional requirements and on non-functionalrequirements other than those related to usability.
You should plan on investing about 30 hours per team member in this group exercise (i.e., 3hours per week). All of the work will be done in the first semester.
1.2 The Clients and System Context
Your clients are the course lecturers. Tim Storer and Rose English. You will have several opportunitiesto meet with and interview the clients about the scope and nature of the group exercise. As you willdiscover the clients will initially have poorly defined and sometimes contradictory notions about therequirements (this is intentional). One of your tasks will be to impose some clarity upon the problemand the system requirements.
2
You will have limited opportunities to speak with other staff and students, but these opportunitieswill have to be kept under careful control to ensure that this exercise doesn't make undue demandson those not directly involved with REM.
The potential users of your system are the staff and students of the School of Computing Science, visitors and, potentially members of staff elsewhere in the university. Clearly defining andunderstanding the user population, their needs, expectations and capabilities, will be one of theproject tasks.
2 D e l i v e r a b l e s
The deliverables for the REM course consist of three draft submissions (D1-D3) and a final submission (D4). Unless advised otherwise, all submissions for REM will be via the REM Moodle page.Submission slots will be made available for each team and deliverable.
2 . 1 I n t e r i m S u b m i s s i o n s
The d ra f t submiss ions a re ;
• a description of group organisation, Dl, due 10am Thursday 27*̂ *̂ Sept;
• a project plan, D2, due 10am Thursday 11'*^ Oct; and
• a requirements specification, D3, due 10am Thursday 1®*^ Nov.
You will receive feedback on each of the draft deliverables, but no grade will be assigned. Therefore, you can make amendments to these items before handing in the revised version as part of thefinal Group Exercise 1 hand-in.
2 . 2 F i n a l S u b m i s s i o n
The final report (D4), due 10am, Thursday 29**̂ Nov consists of:
• a description of your group organisation;
• a project plan;
• a requirements specification;
• a log of major changes, include any substantial changes made to the deliverables (e.g. as aresult of feedback).
3 P e e r A s s e s s m e n t
In order to assess individual contributions to the group exericse, each member of the team shouldprovide a peer-assessment of each member of their team (including themselves!), in terms of thequality of work and effort expended on the group exercise. The peer assessment is used to guide theapplication of a positive or negative delta (from the group award) to the grade for each individualteam member, as appropriate.
To do the peer assessment, you are allocated n x 20 points, where n is the size of your team,which can be divided amongst the team members as you wish. For example: if you have a team of:
• 4 members, you have a total of 80 points to allocate; and
• 5 members, you have a total of 100 points to allocate.
3
If there is a large difference in point allocation among the team members then give a briefjustification for the outlier(5). This information will be used to determine the potential award of apositive or negative delta to each student's overall mark, if appropriate, and at the discretion of thecourse lec turers .
You should submit your peer assessment by email to timothy.storeriSglasgow.ac.uk, before10am, Thursday of Week 18 (17'̂ Jan).
The subject of your email MUST be as follows:[REM Peer Assessment]The assessment must be contained in an attached CSV formatted file with the name:<MATRICULATION NUMBER>_<TEAM>.csvFor example, Sheldon Cooper of Team Blue would attach the file named:1 2 3 4 5 6 7 C _ B L U E . c s vEach line of the file must contain a student's matriculation number and a score separated by a
comma, for example, for a team of four students:1234567c, 212345678w,21 3456789h,21 4567890k,17The justification for the scoring MUST be included in the body of the email, for example:Note: Koothrappali was absent for two weeks, so did less work on theproject. How
ever, the quality of his work was the same as the rest of the team, so I haven't re-allocated manypoints.
4 C o d e o f A s s e s s m e n t R u l e s f o r C o u r s e w o r k S u b m i s s i o n
Deadlines for the submission of coursework which is to be formally assessed will be published in coursedocumentation, and work which is submitted later than the deadline will be subject to penalty as seto u t b e l o w.
The primary grade and secondary band awarded for coursework which is submitted after thepublished deadline will be calculated as follows:
1. in respect of work submitted not more than five working days after the deadline
(a) the work will be assessed in the usual way;(b) the primary grade and secondary band so determined will then be reduced by two sec
ondary bands for each working day (or part of a working day) the work was submittedla te .
2. work submitted more than five working days after the deadline will be awarded Grade H.
Penalties for late submission of coursework will not be imposed if good cause is established forthe late submission. You should submit documents supporting good cause via MyCampus.
Penalty for non-adherence to Submission Instructions is 2 bands.
4
Requirements Engineering M Individual ExerciseTim Storer and Rose English
svn version: 3250
In this exercise, you will write a paper that describes and evaluates some software developmenttechniques and/or notational tools. The purpose of the exercise is for you to demonstrate yourunderstanding of the software engineering discipline, and your ability to independently criticallyanalyse the role of specific principles, methods and practices in the software development process.
1 Background
You work for a small-to-medium sized enterprise (SME) software consultancy, called Solutions forUniversal ERP (SLURP). SLURP advises other organisations on how to modernise existing businessprocesses using enterprise resource planning (ERP) frameworks. ERP frameworks include softwarecomponents for many common organisational functions, such as employee records, financial management and supply chain monitoring. Components are also often available for particular specialistdomains, such as student record management in a university, or timetabling for a public transporti n f r a s t r u c t u r e .
SLURP doesn't develop an ERP framework itself; rather it analyses a client's business processes,licences the appropriate frameworks from ERP vendors and then configures (and potentially customises) the software framework for the client's needs.
SLURP has developed a reputation for expertise working with a variety of ERP frameworks indifferent domains, including:
• a higher education institute, providing a software system for managing all administrative interactions between a student and a university:
• a major supermarket chain, developing a system for integrating demand forecasts, sales andsupply chain monitoring;
• a system for integrating house advertising and sales for a federation of estate agencies (realtors);a n d
• a system for managing guided 'adventure holiday' bookings for a co-operative of outdooractivity instructors.
SLURP's current project method is based on agile practices. The company spends a small amountof time with a small group of future users who act as customers for the required system. Thesesessions are used to develop a small number of user stories, which are short descriptions of featuresto be supported by the system. Based on the analysis, an initial prototype system is developedusing one or more ERP frameworks. These prototypes are then demonstrated to the customers andrequired changes or new features are identified. This process continues until a satisfactory system isdeveloped.
SLURP has found that each of these different domains have very different customer needs andexpectations of the software system to be provided. However, it has been noted that a lot of time isspent on developing user stories with customers that are actually very similar to ones from previousprojects. There have also been several occasions when ambiguity in user stories have caused delaysin project delivery.
1
Several managers have proposed changing requirements documentation processes, so that requirements can be re-used across different projects. In particular, it has been proposed that userstories should in future be documented as use cases and collated into related use case diagrams. Onelong term objective is to have a suite of re-usable use case diagrams describing collections of relatedand recurring features.
The SLURP board is uncertain whether to agree to the extra investment required in the additionaldocumentation efforts required (one board member has noted that the current process is currentlydelivering a reasonable profit), You have been asked to write a report evaluating the suitability ofthe proposal for SLURP, based on any available evidence that you can identify.
2 T a s k
You are to write a short briefing report for the SLURP board. Your report should:
• summarise the main features of requirements gathering and documentation when agile practicesare employed;
• critically assess the suitability of these practices for SLURP;
• provide a description of requirements gathering and documentation in the Rational UnifiedProcess (RUP), using the Unified Modelling Language (UML); and
• critically assess the suggestion of using RUP and UML for requirements gathering and documentation by SLURP.
In preparing your report, you can make use of any lecture notes, the course text books, papers,case studies or other reading material that you have found. In particular, you may find it useful toinvestigate case studies of software development in similar problem domains. Any recommendationsyou make should be supported by the evidence that you find. In all cases, you should cite referencedworks correctly and consistently.
You may find the following papers useful in guiding your reading:
Ian Sommerville. Software construction by configuration: Challenges for software engineeringresearch. In Proceedings of the 21st IEEE international Conference on Software Maintenance,Budapest, Hungary, September 2005. IEEE Computer Society.
Barry Boehm. Get ready for agile methods, with care. IEEE Computer, 35(l):64-69, January2 0 0 2 .
And the following book, which can be borrowed from the University of Glasgow library may alsobe helpful.
Kent Beck and Cynthia Andres. Extreme Programming Explained. XP Series. AddisonWesley/Pearson Education, second edition, February 2005.
The main body of the report should be no longer than 1500 words, not counting figures, captions,meta-data or references. You may use illustrative diagrams if appropriate.
The report should be formatted for review, as follows:
• 25mm margins on all four sides;
• l lpt font;
• double spaced lines; and
2
• s u b m i t t e d i n P D F f o r m a t .
The paper must have a title, author name, author matriculation nurriber and date at the topof the first page. Immediately below this meta-data you must provide an abstract summarising yourfindings. The abstract will contribute to your word count. The report should be written as technicaldocumentation. If you are not sure what this means then consult the software engineering notes(Chapter 9).
3 A s s e s s m e n t
The report contributes towards 15% of the overall grade for REM. The report will be assessed asf o l l o w s :
• description of RUP and agile processes (25%);
• analysis of the suitability of RUP and agile processes to the described context (50%); and
• writing quality (25%).
The band awarded based on this criteria will be reduced by one if the paper is incorrectly formatted. The deadline for this exercise is 10am on Monday of week 18 (17'*^ Jan). Note that thispermits you to submit the coursework after the Christmas vacation. You should submit your paperelectronically in the coursework slot provided on Moodle, labelled 'Individual Exercise CourseworkUpload'. You are not required to submit a hard copy of the paper.
As per the Code of Assessment policy regarding late submissions, submissions will be acceptedfor up to 5 working days beyond this due date. Any late submissions will be marked as if submittedon time, lyielding a band value between 0 and 22; for each working day the submission is late, theband value will be reduced by 2. Submissions received more than 5 working days after the due datewill receive an H (band value of 0).
3
Checklist for Requirements Specification Reviews
O r g a n i z a t i o n a n d C o m p l e t e n e s s
o Are all internal cross-references to other requirements correct?o Are all requirements written at a consistent and appropriate level of detail?o Do the requirements provide an adequate basis for design?o Is the implementation priority of each requirement included?o Are all external hardware, software, and communication interfaces defined?o Have algorithms intrinsic to the functional requirements been defined?o Does the specification include all of the known customer or system needs?o Is the expected behavior documented for all anticipated error conditions?
C o r r e c t n e s s
o Do any requirements conflict with or duplicate other requirements?o Is each requirement written in clear, concise, unambiguous language?o Is each requirement verifiable bv testing, demonstration, review, or analysis?o Is each requirement in scope for the project?o Is each requirement free from content and grammatical errors? \f Jo Is any necessary information missing from a requirement? If so, is it identified as TBD?o Can all of the requirements be implemented within known constraints?o Are any specified error messages unique and meaningful?
Q u a l i t y A t t r i b u t e s
o Are all performance objectives properly specified? Xo Are all security and safety considerations properly specified? Xo Are other pertinent quality attribute goals explicitly documented and quantified, with the
acceptable tradeoffs specified?
T r a c e a b i l i t v
o Is each requirement uniquely and correctly identified? -Jo Is each software functional requirement traceable to a higher-level requirement (e.g., system
requirement, use case)?
Special Issues
o Are all requirements actually requirements, not design or implementation solutions?o Are all time-critical functions identified, and timing criteria specified for them?o Have internationalization issues been adequately addressed?
□ Is the use case a standalone, discrete task?□ Is the goal, or measurable value, of the use case clear?□ Is it clear which actor(s) benefit from the use case?□ Is the use case written at the essential level, rather than as a specific scenario?□ Is the use case free of design and implementation details?□ Are all anticipated alternative courses documented?□ Are all known exception conditions documented?□ Are there any common action sequences that could be split into separate use cases?□ Is the dialog sequence for each course clearly written, unambiguous, and complete?□ Is every actor and step in the use case pertinent to performing that task?□ Is each course defined in the use case feasible?□ Is each course defined in the use case verifiable?□ Do the pre- and post-conditions properly frame the use case?
These notes cover some administrative details for the Requirements Engineering M (REM) course.
1 O v e r v i e w
1 . 1 A i m s
T h e a i m s o f t h e c o u r s e a r e t o : A i m s ( 2 )
• identify the problems in managing large software projects and in specifyinglarge software systems:
• introduce briefly the management problems specific to software development: cost estimation, quality management and team organisation;
• study the generic components of requirements engineering and specification, independently of any particular software development process;
• present a study of object-oriented systems analysis and domain modelling,using UML class diagrams; and
• discuss other approaches to software development, for example extremeprogramming and web engineering.
1 .2 Ob jec t i ves
At the end o f the modu le , a s tudent w i l l be ab le to : Ob jec t ives (3 )
• understand the need for software development processes and methods fordeveloping large information systems;
• describe the processes and techniques required to specify software systemsand to discuss the associated project management problems;
1
• carry out a requirements analysis and write a requirements definition; and
• specify requirements using UML notation, especially use cases and classdiagrams.
2 A d m i n i s t r a t i o n
The ugly face of The lecturers on the course are:software engineering(4) • Tim Storer;
• Jeremy Singer; and
• Rose English.
We will also bring in the odd guest lecturer, when we can, and you will havethe opportunity during the course to talk to software development professionalsworking in industry today.
3 T i m e t a b l e
Course schedule (5) The programme of lectures for the course is as follows:
• l e c t u r e s
- 11am Mondays, Boyd Orr 407- 10am Wednesdays, Adam Smith 718
• laboratories 2-3pm, Boyd Orr 407 or in the laboratory
An approximate timetable for the courses is shown in Table 1.
4 A s s e s s m e n t
Assessment (6) The course assessment is as follows:
• 30% course work, in two parts, each worth 15%
- a group exercise, focusing on requirements capture, specification.domain modelling and evaluation;
- an individual reflective exercise.
• 70% final exam, covering:
- all lecture material, tutorials and workshops,
2
k M o n l l a m - 1 2 p m24'" Sept introduction1 " O c t8 ' " Oc t
planningrequirements 1
5 15'" Oct requirements refinement~~6 22""̂ Oct dynamic modelling~ 29'" Oct change management
~~8 5'" Nov documentation9 12'" Nov quality assurance
To 19'" Nov metricsT T 2 6 ' " N o v
1 2 3 ' " D e c
M e n 2 - 3 p m W e d 1 0 - l l a mintroduction to group exercise the software life-cycleT r a c r i s k m a n a g e m e n tmodell ing with use cases requirements 2
cl ient interviews.U m b r e l l o "Subversion for teams
d e l i v e r a b l eD1 group organisation (draft)
D2 project schedule and plan(draft)
D3 requirements specification(draft)
D4 group exercise 1 report (fi-nal)D5 Reflective Essay
Ta b l e 1 : R E M t i m e t a b l e
— all coursework, and
- all recommended reading.
The emphasis on coursework and team activities will be the most challengingpart of the course. We will introduce the practices and skills you will need to address these challenges during the course. The schedule of coursework deliverablesfor semester 1 is shown in tables 1.
5 R e s o u r c e s
Course Texts (7) There are two text books used for the course;
Ian Sommerville. Software Engineering. International computer science.Addison-Wesley, ninth edition, 2010.
Simon Bennett. Steve McRobb, and Ray Farmer. Object Oriented SystemsAnalysis and Design Using UML. McGraw Hill, Shoppenhangers Road,Maidenhead, Berkshire, SL6 2QL, third edition, 2006.
You should make sure that you acquire at least one of these text books (thereare copies of both in the library) and I have some spare copies of Sommervillethat I can lend out. Sommerville provides a good preliminary introduction tomany aspects of software engineering. Bennett et al. al. gives a comprehensiveintroduction to analysis, specification and design using the UML.
R e f e r e n c e s
Simon Bennett, Steve McRobb, and Ray Farmer. Object Oriented SystemsAnalysis and Design Using UML. McGraw Hill, Shoppenhangers Road, Maidenhead, Berkshire, SL6 2QL, third edition, 2006.
Ian Sommerville. Software Engineering. International computer science. Addison-Wesley, ninth edition, 2010.
