Software Requirements Specification - Google Sites

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


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


-

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


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


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


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


•

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


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


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


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


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


•

• •

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


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


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


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


13.4 Risks •

Deployment problems were not solved in the previous iteration

13.5 Marketing •

TBD

20