Software Project Management, 9th Sep.

Transcription

1 Software Project Management, 9th Sep. Working hour reporting Preliminary analysis Project planning, development models Usability team co-operation Short project presentations on 16th September Course homepage: Lecturer and project supervisor : Timo Poranen, tp@cs.uta.fi, r. B

2 Working hour reporting All work done (except in usability team) will be divided into nine categories: Project planning and management, Requirements specification, Design, Code, Integration and testing, Review, Repair, Studying and Other. See course homepage: Document Templates. Usability team members maintain: Project related working hours, Studying, and Other (usability team meetings, lectures, etc.) and UT managers maintain: Project related working hours, Planning and management, Studying, and Other. In the project homepage, there must be a cumulative working hour table, where different work activities form a matrix. In the weekly reports there must be the total working hours for the period for each project member. 2

3 Development models - Why? Dalcher lists benefits of using a standard development approach: attaining visibility, identifying the tasks breaking work into manageable chunks providing a framework for co-ordinating and managing controlling project finance encouraging systematic evaluation of options and opportunies providing a problem-solving perspective encouraging continuous monitoring managing uncertainty providing a common and shared vocabulary 3

4 Development models - Waterfall Preliminary analysis requirements specification analysis and design implementation testing maintenance. Projects are sequenced into a set of steps that are completed serially. Products are fed into to the next step and frozen upon completition of a milestone. Changes can cause confusion as the project proceeds. It is often difficult to state all requirements in the beginning of the project. Have to see first. The customer must have patience. The first working version will not be available until late in the project time-span. Inspections, reviews and prototypes decrease risk of constructing a wrong product. Compulsory inspections for project plan, requirements specification, test plan and implementation plan. 4

5 Development models - Incremental I Preliminary study requirements specification for each increment: analysis and design implementation and integration testing (fixing) end; maintenance. After requirements specification is ready, it might be possible to split the development phase into several increments. Each increment is designed (increment s content, implementation, unit testing, integration, integration testing) separately. Usually it is wise to construct first most important / most risky part of the software. There is no need to design whole implementation before you can start coding. Client (and usability team) can give feedback earlier, just after the first increment is ready! 5

6 Development models - Incremental II What if you choose wrong architecture for the first increments? Refactorisation of the code or start the design from the beginning... Increments can be parallel. The lenght of an increment should be 2-3 weeks in this course. Number of increments? 3-7? Sometimes it is possible to start increments before all requirements are recognised. Inspections in this course: Project plan, Requirements specification, and reviews for two increments. The design and test plan documents can be divided into increments. 6

7 Other development models It is ok to apply any widely recognised (and documented) model: Scrum, XP, other Agile models, iterative, prototyping,... Inspections in this course: Project plan. Three reviews for iterations. In the reviews team gives a demo on achievements of the previous iteration. Then we check requirements, design and test documents for the next iteration. You define the reviews in the project plan. In total: 6-7 iterations and their reviews? You should follow your development model s recommendations. For example, It is necessary that you produce partially running software much earlier when compared to WF. 7

8 Development models - References Pressman, R.:Software Engineering - Practitioner s approach, 6th edition, pages: Sommerville, I.: Software Engineering 7, pages: 63-91, Hughes and Cotterell: Software Project management. Benediktsson, O., Dalcher, D. and Thorbergsson H.: Comparison of software development life cycles: a multiproject experiment. IEE Proceedings Software, 153(3), June 2006, Abrahamsson et al.: Agile software development methods: review and analysis, 2002 Wikipedia, youtube. 8

9 Preliminary analysis meeting with the course supervisor See Document Templates, Preliminary analysis. Deadline The document must be returned to the supervisor 24 hours before the meeting. Reserve 30 min timeslot from the lecturer by . Reserve a meeting room. Free timeslots: 9

10 Project Plan For a project plan we will apply a template based on IEEE 1058 standard. See Document Templates. All (main) tasks and deliverables should be mentioned in the plan (if possible, agile projects?). Start date, end date, how many hours it will take, who is in charge. Start to design project plan with your group and client as soon as possible. The inspection deadline is Friday Sen the document to all stakeholders 5 days earlier. Require that all read carefully the document. It is important to introduce your development model and how you apply it! Plan must be updated regularly. 10

11 Usability team - Kajaste, I., Mathew, D., Peltomäki, S. and Poranen, T.: Using usability experts to improve software quality, 2007, http: // Usability team has 10 PW students and 2 managers: Ari Koivuniemi and Jonna Paananen. One (or more) student from the usability team co-operates actively with your team if you have any usability needs. He or she is your team member. Share project s information with UT member and UT project managers. UT managers will inform within two weeks, who is your usabilityn team representative. See usability team project stories to see what kind of deliverables usability team produced last year. 11

12 Co-operation with the usability team... A great benefit from this co-operation is that you get usability related documents and external feedback from the usability team. The team members will also help in usability tests. This makes managing slightly more complex, but gives realism to the projects. Send your project information to the usability managers! Co-operation guidelines will be discussed on the next week after UT presentation. The project plan should also contain all usability related tasks (their start date, end date, person in charge, how many hours it takes,...)! Add UT representative to your weekly report mailing list and make sure that they really belong to your team. 12

13 2 managers for one project? You can decide your own responsibility areas. You should prepare for meetings etc. together before the meetings. It is ok if managers move from a passive role to an active role and vice versa during the project. To avoid possible problems, pay attencion on communication and planning to get a common view for important issues. Roles: quality manager, risk manager, scrum master,... 13

14 Technical help for projects To work in projects, department s computer classes can be used. For some projects, client gives equipments, for most projects not. Department has, for example, subversion installed. If you need user accounts for subversion, send an to the lecturer and (jori.mantysalo@cs.uta.fi (room B , Mondays 8-12, Tuesdays 12-16, Thursdays 8-12 and Fri 12-16). You need a name for your project before that. You can add and remove users normally. Tuomas Tauriala helps if there is a need for virtual servers (Tuomas.Tauriala@uta.fi, room B1052). 14

15 Short presentations on 16th September Each project manager gives a 7 minutes presentation: Introduce your project shortly. Describe what kind of group you have. Meetings, communication with the client, communication with the group... Main project risks, how to avoid them. Development model Other management related issues. 3 minutes time for questions and discussion. Presentation schedule: First presentation starts 10:15 last ends Let s try to maintain the schedule in the Moodle! So, reserve your project s 10 minutes from the Wiki Presentations

16 Other important topics Common problems in requirements specification Common problems in design document Common problems in test plan Reviews/inspections Course homepage: Lecturer and project supervisor : Timo Poranen, tp@cs.uta.fi, r. B

17 Problems in Requirements Specification Missing requirements, use cases / user stories. Missing use case and sequence diagrams (UML). Database tables and fields (UML class diagram). QualityRequirementsChecklist-RM.doc: correctness, comprehensibility (unambiquity, right level of detail), completeness, consistency, priorities. Place requirements into groups. Use understandable IDs, not REQ In the end requirements specification must correspond to the actual implementation. UI specification? Usability requirements? 17

18 Problems in Design Document There must be architectural diagrams (component diagram or deployment diagram or package diagram or composite structure diagram) and a class diagram (UML). Missing definitions for some (interface) functions. No list of error messages or program files with their descriptions. All database data must be defined. UI documentation is missing or it is not tied with design document (which function is called when I press this button?). 18

19 Problems in Test Plan Not all features are tested - There must be at least one test for each requirement. For each test case, write down which requirements it tests. Use a text file to store all test inputs. (Automated) Unit testing? Testing diary? Start testing after first classes/components are ready. Make sure that you have enough time for testing. Output from testing is a test report. From the test report one can verify that you have done tests and that corresponding requirements are implemented correctly. 19

20 Inspections and reviews Contents How these do relate to projects? What can be reviewed? Goals of reviews. Benefits of reviews and inspections. Review and inspection methods. How the reviews are arranged on the project work courses. Original slides by Isto Aho. Modified by Timo Poranen. 20

21 Goals and benefits Early recognition of faults, miscomprehensions and problems. cheaper and easier to correct faults can be found from functioning, logic and implementation. reviews expose different faults than testing. Teaching method inexperienced may learn from the experienced (is a mentoring method). Client may set requirements with regards to reviews. Client acceptance and opinion. To agree on the parts of product that either don t need or which we don t want to improve. 21

22 More goals and benefits Quality assurance. Is related to standards, like ISO 9001 and IEEE Ensure that software meets its specification and requirements. Ensure that software and its functioning will be represented by methods and standards defined beforehand. Ensure that software is developed with uniform methods. 22

23 More goals and benefits Nowadays reviews are an essential part of WF model. Project is more manageable. The technical quality of work will improve and is more uniform. The project tracking will be clearer, the predictability of progress and success improves. Ensures and improves the continuity of project, since people will get familiar with the parts they have not seen before. 23

24 Reviews, inspections, walk-throughs Inspection: A static analysis technique that relies on visual examination of development products to detect errors, violations of development standards, and other problems. Review: A process meeting during which a work product, or set of work products, is presented to project personnel, managers, users, customers or other interested people for comment or approval. Walkthrough: A static analysis technique in which a designer or programmer leads members of the development team and other interested parties through a segment of dicumentation or code, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems. 24

25 What to inspect? All material that will be produced: documents, for example requirements specification project plan testing plan implementation plan instruction manual 25

26 code review reports (meeting minutes) progress reports (weekly reports) test reports running software, release plans in XP, increment plans etc. If some document or other product is very large, it should be reviewed with partial reviews (e.g., max about 50 pages or 500 lines of code at a time). 26

27 Fagan s Inspection Design (planning): who will take part, sharing material, agenda for the inspection. Preparing: participants get familiar with the material beforehand, each separately. Meeting: the length is limited (max 2 hours), discussions will be focused, problem cases will be brought up but are not solved here. Repairs: after the meeting, the problems should be fixed. Continuity: ensure that the problems have been fixed (correctly). 27

28 Example inspecting implementation plan This example focuses on the preparing and meeting phases. Design (planning): Each participant will get the implementation plan. Ensure that everybody has the requirements specifications and agenda. Preparings: Everybody will get familiar with the material (implementation plan) and mark the faults found. To ease the reading, check lists can be given. The idea is help to find out the problems. 28

29 Example inspecting implementation plan Meeting: Length at most 2 hours. Roles for the participants. We go though the document page by page or section by section or chapter by chapter. Purpose of the meeting: Each will show the problematic parts they have found. New problems are sought actively. The implementation plan is checked systematically (e.g., with the help of use cases or standards). Ensure together that everybody has a common view learning. 29

30 Eliminate wrong problems (problem candidates that the group will decide not to be problems). 30

31 Roles Leader: leads the meeting, keeps with the time schedule, limits debate, rebuttal and, explanations, and encourages or provoces passive. Secretary: will take written notes, especially the problem cases (e.g., inspection form). Project manager: checks that corrections are done. Other participants do not have a role related to organizing the inspection. Instructions for the producer: do not bring an unfinished product to be checked. 31

32 Check lists These help in the preparing phase. Participants will use these when they get familiar with the review object. Check lists: a set of questions, with which the readers attention can be focused to the desired cases. In the example, part of the list items maybe based on requirements specifications. Other part can be based on standards and used software process (which have been agreed to be followed). 32

33 More instructions on reviews The following list is from Pressman s book: Review the product, not the producer. Set an agenda and maintain it. Limit debate and rebuttal. Enunciate problem areas but don t attempt to solve every problem noted. Limit the number of participants and insist upon advance preparation. Develop a checklist for each product that is likely to be reviewed. Allocate resources and time schedule for reviews. Conduct meaningful training for all reviewers. Take written notes. Review your early reviews. 33

34 References Pressman, Software Engineering, A Practitioner s Approach Haikala ja Märijärvi, Ohjelmistotuotanto Hughes and Cotterell, Software Project Management ISO standards (e.g. Schmauch, ISO 9000 for Software Developers, or IEEE -standards (especially IEEE 1028, IEEE Standard for Software Reviews and Audits, 34