BugRep Software Project Plan Academic College of Tel-Aviv Yaffo Software Engineering Course Year 2006-2007 Project lead names Shmuel Tyszberowicz, Yair Aviv Project name BugRep Document Software Project Plan Document Version 0.2 Last update date 10/06/2007 Date First Version 25/03/2007 Team Members: Name
ID#
e-mail
duty
Irit Lovenberg
033145558
[email protected]
Tests manager
Yael Shemla
034279125
[email protected]
Requirements manager
Sagy Rozman
038356036
[email protected]
Implementation manager, Design manager
Chen Levkovich
033026055
[email protected]
Software configuration manager, SQA manager
Galit Daniel
034188334
[email protected]
Team Leader
1
BugRep Software Project Plan Revision Sheet Revision Number
Date
Brief Summary of Defects
0.1
25/03/2007
Baseline draft document
0.2
06/10/2007
Added second iteration planning
2
BugRep Software Project Plan Confirmation Sheet SQA manager
Team Leader
Name
Software Configuration Manager Chen Levkovich
Chen Levkovich
Galit Daniel
Signature
Chen Levkovich
Chen Levkovich
Galit Daniel
Date
25/03/2007
25/03/2007
25/03/2007
Author
3
BugRep Software Project Plan
TABLE CONTENTS 1
INTRODUCTION.............................................................................................. 6 1.1 PROJECT OVERVIEW ..................................................................................... 6 1.2 PROJECT DELIVERABLES ............................................................................... 6 1.3 DOCUMENT OVERVIEW ................................................................................. 6 1.4 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS ......................................... 7 1.4.1 Key Definitions .................................................................................... 7 1.4.2 Key Acronyms and Abbreviations........................................................ 7 1.5 KEY REFERENCES ......................................................................................... 7
2
ITERATIONS PLAN......................................................................................... 8
3
PRODUCTS........................................................................................................ 8
4
METHODS, LANGUAGES, AND TOOLS .................................................... 9 4.1 4.2 4.3
5
WORD (FOR REQUIREMENT) ......................................................................... 9 JAVA ............................................................................................................. 9 NETBEANS .................................................................................................... 9
ROLES IN TEAM.............................................................................................. 9 5.1 PROJECT MANAGER ...................................................................................... 9 5.2 REQUIREMENT MANAGER............................................................................ 10 5.3 DEVELOPMENT MANAGER ........................................................................... 12 THE DEVELOPMENT MANAGER (ALSO KNOWN AS SOFTWARE CONSTRUCTION MANAGER) IS RESPONSIBLE FOR THE CODING VERIFICATION, UNIT TESTING AND DEBUGGING OF THE SOFTWARE. .............................................................................. 12 5.4 SOFTWARE QUALITY ASSURANCE MANAGER ............................................. 13 5.5 DESIGN MANAGER....................................................................................... 14 5.6 TEST MANAGER ........................................................................................... 15 5.7 CONFIGURATION MANAGER ........................................................................ 16
6
PLANNING, TRACKING AND REPLANNING......................................... 17 6.1 6.2 6.3
PLANNING ................................................................................................... 17 TRACKING ................................................................................................... 17 REPLANNING ............................................................................................... 17
7
PLANNED DOCUMENTS PEER REVIEWS.............................................. 17
8
PLANNED SOFTWARE (PROTOTYPES) PEER REVIEWS .................. 17
9
RESOURCES ................................................................................................... 18
10
MONTHLY EFFORT ................................................................................. 18
11
TRACEABILITY MAPPING..................................................................... 18
12
FIRST ITERATION PLANNING.............................................................. 18 DEFECT MANAGEMENT ........................................................................................... 18 12.1 SCHEDULE................................................................................................... 18 4
BugRep Software Project Plan 12.2 12.3 12.4 12.5 13
MAIN FUNCTIONALITIES.............................................................................. 19 INFRASTRUCTURE ARCHITECTURE .............................................................. 19 RISKS .......................................................................................................... 19 MARKETING ................................................................................................ 19 SECOND ITERATION PLANNING......................................................... 19
PROJECT AND USER MANAGEMENT ......................................................................... 19 13.1 SCHEDULE................................................................................................... 19 13.2 MAIN FUNCTIONALITIES.............................................................................. 19 13.3 INFRASTRUCTURE ARCHITECTURE .............................................................. 19 13.4 RISKS .......................................................................................................... 20 13.5 MARKETING ................................................................................................ 20
5
BugRep Software Project Plan
1 Introduction 1.1 Project Overview The BugRep tool enables the automation, tracking and analysis of reporting defects in the company's software products. Users of this product will be able to report defects, track progress of defect handling, and change status of defects according to organizational needs and demands. The product will be highly adaptable and configurable and therefore its intended users are of different size and nature, such as: • Management of the specified software, at all levels – relevant team that uses this tool as a means for appreciating the status and project. • Development team working on the relevant software – use this tool for monitoring and updating the status of the defects detected in the software under their responsibility. • Testing team in charge of the quality assurance of the relevant software – user this tool for registering the detected defects and monitor their status. • Customer related teams – use this tool for registering the problems detected during the day-to-day work with the relevant software. The development of the BugRep tool is divided into 5 software versions and is planned to be finalized by the end of June.
1.2 Project Deliverables As mentioned above, the deliverables of the BugRep tool are 5 software versions and additional documentation deliverables. The due dates of the software deliverables are as following: • First Version 5/5/2007 • Second Version 19/5/2007 • Third Version 2/06/2007 • Fourth Version 16/06/2007 • Fifth Version 30/06/2007
1.3 Document Overview The purpose of this document is to outline the Bug Rep tool project plan. This document project plan consists of the following sections: - General description of the tool and the target audience intended to use it (this chapter).
6
BugRep Software Project Plan
-
High level overview of the iteration and deliverables planning including timeline. High level overview of the team structure and the relevant roles and responsibilities of each team member.
1.4 Definitions, Acronyms, and Abbreviations 1.4.1
Key Definitions
1.4.2
Key Acronyms and Abbreviations
ANSI
American National Standards Institute
CMU
Carnegie Mellon University
DFD
Data Flow Diagram
IEEE
Institute of Electrical and Electronics Engineers
RTM
Requirements Traceability Matrix
SCM
Software Configuration Management
SEI
Software Engineering Institute
EPG
Engineering Process Group
SMM
Software Measurement and Metrics
SQA
Software Quality Assurance
SRS
Software Requirements Specification
PM
Project Manager
RM
Requirement Manager
DM
Design Manager
1.5 Key References [1]
SWEBOK
[2]
SRS Document
Software engineering body of knowledge Software Requirements Specification
7
BugRep Software Project Plan
2 Iterations Plan We are planning 5 iterations. #Iteration
Start Date
End Date
Time Interval
Defect Management
15/04/2007
05/05/2007
3 weeks
Project and User Management
06/05/2007
11/06/2007
4 weeks
Reporting Management
11/06/2007
24/06/2007
2 weeks
Customized statemachine
7/07/2007
21/07/2007
2 weeks
3 Products Product Name
Delivery Date
Initiation document
12/11/2006
SRS Peer Review
04/01/2006
SRS
10/04/2007
Design Peer Review
19/04/2007
Design
26/04/2007
Test plan
26/04/2007
First Iteration Peer Review
03/05/2007
First Version
05/05/2007
Second Version
11/06/2007
Third Version
24/06/2007
Forth Version
21/07/2007
8
BugRep Software Project Plan
4 Methods, languages, and tools 4.1 Word (for Requirement) 4.2 Java 4.3 Netbeans
5 Roles in Team 5.1 Project Manager The PM is responsible to the application management activities which include planning, coordinating, measuring, monitoring, controlling and reporting to ensure that the development and maintenance of the software are systematic, disciplined and quantified. The PM role consists on management and measurement. The PM is responsible of six sub areas: 1. Initiation and scope definition The PM determines the scope of the project, objectives and constraints. The PM must be assured that adequate capability and resources are available in the form of people, expertise, facilities, infrastructure and support. 2. Software Project Planning The PM selects the appropriate life cycle and determines the deliverables. The PM is responsible for the schedule, effort and cost estimation in essence of allocating resources to tasks and for determining the risks, quality and management plan. 3. Software Project Enactment The PM prepares and executes agreements with suppliers, monitors supplier performance and accepts supplier products. The PM is also responsible to implement of the project plans throughout monitoring and controlling the process and may change the plan if required. Reporting to the organization and the stakeholders about the progress the
9
BugRep Software Project Plan
plans is required on a periodical basis. 4. Review and Evaluation The PM determines periodically the stakeholders' satisfaction of the requirements. In all appropriate actions that are taken, change control and software configuration management procedures are adhered to, decisions are documented and communicated to all relevant parties. Plans are revisited and revised when necessary and reviews are being done periodically to personnel who provide insights as to the likelihood of adherence to plans as well as possible areas of difficultly. 5. Closure The PM determines the closure of the project according to the planned products that delivered, to the requirement that checked off and confirmed as satisfied and according to the objectives of the project that have been achieved. These processes involve all the stakeholders. The PM is also responsible to closure activities such as archiving of the project, analysis the issues, problems and opportunities encountered during the process, drawn from the process lessons for the organization. 6. Software Engineering Measurement The PM defines the scope of measurement and commits resources for them; assigning resources includes allocation of responsibility for the various tasks of the measurement process. Moreover, planning of the measurement process, characterizing the organization unit, identifying information needs, selecting measures, and defining data collection for analyses, and reporting is required. The PM performs the Measurement process (by collect analysis and communicating the results to the peers). All the information products are being evaluated and the PM determines the results strengths’ and weaknesses’.
5.2 Requirement manager Requirement Manager is responsible for defining and managing software requirements across the five critical requirements process areas: elicitation, analysis, specification, validation and management. The following paragraphs will provide a brief explanation about the role of RM in each area: 1. Requirement Elicitation The RM should be concerned with where software requirements come from and how the software engineer can collect them. The last two questions deals with: • Identification of sources (i.e. goals, domain knowledge, stakeholders, operational environment),
10
BugRep Software Project Plan
•
Adopted techniques (i.e. interviews, scenarios, prototypes, facilitated meetings, observations).
2. Requirement Analysis The RM should detect and resolve conflicts between requirements, discover the bounds of the software and how it must interact with its environment, and elaborate system requirements to derive software requirements. In order to achieve the aforementioned demands, RM uses the following methods: • requirement classification (i.e. functional/non-functional, product/process, priority, scope, and volatility/stability) • requirement modelling; as an aid for understanding the problem (e.g. using UML) • Architectural design and requirements allocation • Requirements negotiation; this method is required when there are conflicts between two stakeholders requiring mutually incompatible features, in this cases the RM should reach a consensus on an appropriate trade-off. 3. Requirement Specification In this area RM role is production of document, such that it can be systematically reviewed, evaluated and approved. For complex systems, particularly those involving substantial non-software components, as many as three different types of documents are produced: system definition document, system requirements and software requirements. 4. Requirement Validation RM should ensure two important things regarding this area: first is that the software engineer has understood the requirements, and second is that all requirements document conform to company standards, and is understandable, consistent and complete. The RM is responsible of accomplishing it using the following methods: • Requirements review (i.e. assign representative group of reviewers for a brief look for errors, mistaken assumption, lack of clarity and deviation from standard practice). • Prototyping (i.e. means of validating the software engineer's interpretation of the software requirements). • Model validation (i.e. quality validation of models developed during analysis phase). • Acceptance tests (i.e. plan how to verify each requirement). 5. Requirement Management. As product start to evolve, companies discover that they need to recover the requirements that motivated product features in order to assess that impact of proposed changes. Hence, requirements documentation and change
11
BugRep Software Project Plan
management are key to success of any requirement process. The RM executes these using the following methods: • Iterative nature of requirements process; in almost all cases, requirements continues to evolve as design and development proceeds. This often leads to the revision of requirements late in the life cycle. • Change management, which concerned with the procedure that need to be in place and the analysis that should be applied to proposed changes. Change has to be managed by ensuring that proposed changes go through a defined review and approval process. • Requirement attributes, this method refer to ancillary information which helps manage and interpret the requirements, which means various classification dimensions of the requirement and verification or acceptance test plan. • Requirement tracing, this method is concerned with recovering the source of requirement and predicting the effect of requirement change. • Measuring, this method interested in a practical meter for evaluating the "size" of a change in requirement, in estimating the cost of development and maintenance tasks. Above all this, the RM should make sure that requirements adhere to the following characteristics: Quantifiable, Verifiable, and Prioritized. Requirements should be stated as clearly and as unambiguously as possible, and where appropriate, quantitatively. It is very important to avoid vague and unverifiable requirements which depend for their interpretation on subjective judgment. In addition, requirements priority rating is extremely important since it enable trade-offs in the face of finite resources and a status value, to enable project progress to be monitored.
5.3 Development manager The development manager (also known as software construction manager) is responsible for the coding verification, unit testing and debugging of the software. The input to the construction phase is the design and the output is the source for the testing, although depending on the software life cycle process these boundaries tend to blur. For example in a highly iterative process such as Extreme Programming, a lot of the design work is performed while in the construction phase. In other – more linear processes such as Waterfall the software construction manager’s role is minimized to coding and a much greater emphasis is given to the detailed design which is done upfront. The fundamental responsibilities of the construction manager are:
12
BugRep Software Project Plan
1. Minimizing complexity Emphasizing the creation of code that is simple and readable (rather than clever), through the usage of coding standards 2. Anticipating change Building software that will support change as requirements change. This is achieved by using different coding and testing techniques, languages and tools. 3. Construction for verification It is the software construction manager’s role to ensure a product which can be easily tested and verified. This can be achieved by writing unit tests (also known as developer tests), restricting the usage of complex or hard to understand software constructs, and following a given set of coding standards. 4. Following standards in construction The development manager should adhere to external standards, issued by bodies such the OMG or IEEE and ISO. Internal standards which relate to the organizational or corporate level should also be defined and followed. Some of the measurements used and collected by the development manager are the amount of code developed, code modified, code reused, code complexity, number of bugs found and fixed, etc. 5. Testing in the context of software construction The development manager is responsible for testing activities which relate to the construction of the software, specifically the unit tests and integration tests. Both are performed and written by the software construction team. In some construction models the tests are written after the coding. In others (such as Extreme Programming) the tests are written before the code which is known as Test Driven Development. 6. Construction quality It is the responsibility of the development manager to ensure the quality of the construction product. The tools used for this purpose are unit tests and integration test, Test driven development, usage of assertions, technical code reviews. The focus in the construction quality is on the code and the small scale design.
5.4 Software Quality Assurance Manager This position oversees all employees and functions of the Software Quality Assurance (SQA) Department. The incumbent will ensure that goals are set and that the mission of the department is communicated clearly to all. It is the sole responsibility of this position to intervene when situations escalate. This position will also provide guidance and coaching to all subordinates. The SQA
13
BugRep Software Project Plan
manager has the ability to be influential on technology used and should stay knowledgeable of new software and suggest upgrades as needed. 1. Report bugs, create and provide metrics on bugs as they move through the bug cycle 2. Communicate the status to all involved departments 3. Report environment changes that effect clients (internal or external) to the Development manager and Tests manager 4. Update, oversee and train team on the knowledge base of code related problems and fixes 5. Facilitate fixes through software development lifecycle 6. Track where each bug is in the process 7. Report turnaround times on all severities 8. Track bug trends 9. Track and monitor fixes and problems reported 10. Create and manage Internal Release Notes (i.e. what bugs where pushed, what was fixed, how many new bugs were created) 11. Document test use scenarios and processes 12. Train team on documentation of processes and scenarios
5.5 Design manager The design manager is responsible for the definition of the architecture, components and interfaces of a software system at a level of detail that enables their construction. There are two levels of design: • Software architectural design (also called top level design) Describes how software is decomposed and organized into components • Software detailed design – Describes the specific behaviour of these components Some of the key issues that the DM must handle are quality related – for example the system performance and also the decomposition, organization and packaging of the system into highly cohesive and low coupled modules. Other issues involve cross-cutting concerns which relate to the semantic behaviour of all or a subset the modules of the system and are called aspects. 1. Defining the software structure and architecture: It is the responsibility of the design manager to define the internal structure of the resulting software. The architecture of a software system can be described and documented using facets or views. Different aspects of the system which are orthogonal for example: the functional view vs. the structural view vs. the behavioural view vs. the data modelling view. 2. Detailed design and design patterns
14
BugRep Software Project Plan
A pattern can be defined as a common solution to a common problem in a given context. In the context of software design, patterns can be used by the design manger to described the detailed or lower level design – also known as micro architecture. A part of the design mangers role is to identify and design software product lines also known as Frameworks. In the context of Object-Oriented software construction Frameworks are defined as a partially complete software subsystem that can be extended by appropriately instantiating specific plugins. 3. Quality related software design issues The quality of the design can be measured by different attributes such as maintainability, robustness etc. Some are related to run time performance, while other is non runtime related (such as reusability or testability). The design manager can use design reviews to ensure the high quality of the software’s design. Other quality measurement tools are static analysis and simulation and prototyping. 4. Software design notations The design manager can use a set of tools and notations to describe the structural (static) and behavioural (dynamic) attributes of a software system.
5.6 Test manager Testing is an activity performed for evaluating product quality, and for improving it, by identifying defects and problems. Software testing is seen as an activity which should encompass the whole development and maintenance process and is itself an important part of the actual product construction. Planning for testing starts with the early stages of the requirement process, and test plans and procedures are systematically and continuously developed, and possibly refined, as development proceeds. Following are roles and responsibilities of the test manager: • Recruit and manage the testing team staff • Plan test budgeting and scheduling including test effort estimations • Test planning including development of testing goals and strategies • Selecting and introducing the test tools and environments • Verifying the quality of the requirements, including testability, requirement definition, test design and test execution • Analyze requirements and coordinate the planning and execution of test cases • Identify, report and track defects in the software • Design and develop test scripts, if relevant, (manual or automated) • Manage and perform different levels of testing (depending on the software nature), such as. o Unit Tests (Design Assistance only) – Since these tests are usually performed by development team, the role of the testing manager in this
15
BugRep Software Project Plan
•
• •
case is to work closely with the development team and assist them in their unit test design and other quality-assurance related issues o Integration Tests – The testing process for verifying the interaction between different software components o System Tests – Tests hat attempt to discover defects that are properties of the entire system rather than of its individual components o Regression Tests – Selective retesting of a system or component to verify that modifications have not caused unintended effects o Performance Tests – Tests that are aimed at verifying that the software meets the specified performance requirements, for instance, capacity and response time Test the software using various testing techniques, such as o Tests based on the software engineer’s intuition and experience with similar programs. o Specification-based tests – verify that the software is aligned with the relevant specifications o Code-based techniques – Tests that are aimed at covering all the statements or blocks of statements in a program, or specified combinations of them o Application-related tests – Tests that are based on the nature of the application, such as object-oriented testing, component testing, etc. Produce and continuously update relevant test documents, for example, Test Plan, Test Design Specification, Test Procedure Specification, Test Case Specification, Test Log, and Test Incident or Problem Report. Issue status reports that reflect the actual status of the different testing stages. These reports may cover such aspects as number of test cases specified, number of test cases executed, number of test cases passed, and number of test cases failed, among others.
5.7 Configuration manager 1. Coordinate software releases by maintaining documentation such as Environmental plan, release notes, release baseline documentation, and other artifacts required for the release. 2. Participate in project planning and coordination for major launches and upgrades. 3. Manage source control management system 4. Write and maintain application build scripts 5. Write and maintain application deployment scripts 6. Analyze and trouble shoot deployment issues 7. Install software into the various environments based on build requests submitted by the project manager or development team. 8. Ensure all build requests are associated with an approved scope item.
16
BugRep Software Project Plan
9. Publish a final build document to the Development teams for review and approval prior to movement of code to the client environment.
6 Planning, Tracking and Replanning 6.1 Planning We are planning 3 iterations throughout the version. The version will be tested and according to the feedback we'll decide whether to publish the version or fix it. For the fist version we will do a peer review 2 weeks before it will be published.
6.2 Tracking The team leader will track the schedule on a weekly basis. At the end of each month the team leader will examine the number of open calls against the closed ones, this will be another parameter whether to release the version or time or not.
6.3 Replanning The team leader will decide to either descope features or defer them to the next version in case there will be a fall behind schedule. The team leader will decide whether it's required to delay the release date of the version.
7 Planned Documents Peer Reviews Peer Review
Delivery Date
SRS Peer Review
04/01/2006
Design Peer Review
19/04/2007
8 Planned Software (prototypes) Peer Reviews Peer Review
Delivery Date
First Iteration Peer Review
03/05/2007
17
BugRep Software Project Plan
9 Resources 1 Team leader 1 Requirement manager 1 Development manager 1 Software quality manager 1 Design manager 1 Test manager 1 Configuration manager
10 Monthly Effort It is planned for each member in team 4 hours for a week (16 for months). Monthly effort for the team is 64 hours.
11 Traceability Mapping In order to enhance and complete the quality assurance process (as described in test manager role, see section 5.6), we have to perform traceability map, which document the links through User Requirements, items in the Design Model, Source Code units, Tests and User Documentation. Moreover, this process must be executed through all phases of software life-cycle to ensure capture and consideration of new software requirement or design changes. Information about the two ways mapping between the aforementioned subjects will be provided in one of the tests documents.
12 First Iteration Planning Defect management 12.1 Schedule Begin 15/4/2007 End 5/5/2007
18
BugRep Software Project Plan
12.2 Main functionalities • • •
Defect CRUD Defect details screen Search and Filter Defects
12.3 Infrastructure architecture •
Use Java DB
12.4 Risks •
Design complications The design phase has not started. Some unexpected complication might evolve. • Not all team members are familiar with the technology Due to short time frame, the team members will have to study the technology during the development phase. It might delay the first iteration. • Backend development might take more time than expected, and/or might no meet the requirements.
12.5 Marketing •
TBD
13 Second Iteration Planning Project and User management 13.1 Schedule Begin 6/5/2007 End 11/6/2007
13.2 Main functionalities • •
Project and User CRUD Project and User screen
13.3 Infrastructure architecture •
Use Java DB
19
BugRep Software Project Plan
13.4 Risks •
Deployment problems were not solved in the previous iteration
13.5 Marketing •
TBD
20
