The year is 2072. Your company (Netscoop) has pitched the need for a revolutionary new browser that is needed to field before Christmas 2072--- Netscoop Navigator. The industry has stiff competition so it will be important that it meets the needs of the users.

This browser is slated to be first of its kind in that it will be able to service requests to /GET content using a new protocol (HTML) from the world wide web (WWW). Content will then be rendered into the Netscoop Navigator browser.

With Netscoop Navigator, users will be able to move forward and backward through the WWW utilizing a revolutionary new concept “hyperlinks”. Images will be supported of various high-resolution formats such as BMP and GIF. Music additionally can be played in a loop in the background of MIDI type. Users can choose to upgrade their to Netscoop Navigator+ version via the tool itself which adds JPEG and MP3 for an extra price. A service additionally runs in the background and will queue the user to update when there is a new update available.

 Other basic implicit capabilities will be available (File=> open/close, About, Help). Button capabilities (combo boxes, text, fields, etc.) and multiple windows (tabs) were desired but determined not to be viable within the timeframe provided to field before Christmas.

Additionally, since there has been a recent wave of Phishing Attempts using the Snail-Mail e-mail service/app which will launch the browser. Netscoop can be toggled into a trusted mode where a user must approve each web-site access request in turn when clicked. This will add it to a whitelist of websites that are trusted and maintained in a user profile file on the system. Once added it will not prompt the user again.

1. Project Background (PART 1)

The background should be abridged from a typical project proposal but may have some intersections. To set the stage, assume the funding is already committed, but stakeholders want to understand more about your chosen implementation to validate your understanding of the top level assumptions of the system.

The background should set the stage for the content to follow, and address some of the big picture issues.

Some questions to consider / address include the following:

• What are the purposes of the software?

• Who will use it? And where / how?

• What factors are likely to influence the economics of product development, choice of technology etc...

• What kinds of external inputs and outputs exist?

• Are their significant technical risks in development?

• Who is responsible for system development and operation?

• What are the roles and responsibilities of the main groups of people working on the system development (e.g., architects, engineers)?

• In a high-level sense, what kinds of information passes among these groups of people?

• What tools will be utilized? Development, integration/test?

• What platform will it run on?

• Who are your developers? Where are they located? What’s their experience level? Are they multi-site? What’s their work week?

• Who is responsible for building and testing, operating and maintaining the system?

• Are there reliability considerations to consider?

• How novel is this application? Are we breaking new ground?

• Additionally review the "W5H2" slide in Module 2 S/W Process & Effort Estimation and ensure your background addresses those items.

• Any other questions worth considering... (Up to you)

2. Program Plan (PART 1)

The program plan should provide an understanding of cost/schedule and inform stakeholders as to how the project will be executed.

The program plan should select a software process model, and describe the rationale for why it was selected (NOTE: the rationale should be relevant to the project selected.)

The program plan will include

• Organizational Breakdown Structure (OBS): Should have focus on various engineering groups who will be your organization

• Work Breakdown Structure: Should include tasks necessary to complete work. As an example it should include but is not limited to Software Tasks, Financial Tasks, Testing Tasks, and Project Management Tasks. (Feel free to use the template provided in the Files area of the course)

• Integrated Master Schedule (IMS): A cartoon schedule is ok with incremental milestones and deliverables . (Feel free to use powerpoint or alternatively one of the tools suggested in Module 3 to more easily construct your plan)

The program plan will also include a Basis Of Estimate (BOE) targeted specifically for the software development engineering effort (development, test, etc.). Justify salary levels based off the region and experience level you select: http://www.salary.com (Links to an external site.) or other salary tool. Assume 1.4x Burden Rate. (Feel free to use the template provided in the Files area of the course

The BOE should attempt to estimate software effort utilizing one of the following techniques:

• A) COCOMO II w/ WideBand Delphi strategy

o Wideband Delphi: The software effort estimation should employ Wideband Delphi with estimates provided by each team member to estimate total SLOC. A documentation of the steps in the process should be accounted including constraints / assumptions that each team member made during each round. You should iterate until consensus is reached and no substantive change is employed. If working by yourself only one round is required.

o COCOMO II: The SLOC should come from the prior step and assume 80% new code, 10% modified, and 10% reused code. A rationale for each attribute should be selected utilizing justifications tracking to project background if applicable. Fill in the gaps and make assumptions for content not provided in the background.

• B) Function Points w/ WideBand Delphi:

o Wideband Delphi: The software effort estimation should employ Wideband Delphi with estimates provided by each team member to estimate 14 degrees of influence and complexity. A documentation of the steps in the process should be accounted including constraints / assumptions that each team member made during each round. You should iterate until consensus is reached and no substantive change is employed. If working by yourself only one round is required.

o The software effort estimation should assume data as outlined below. For each of the 14 degrees of influence and weighting factors, the team should rate accordingly, and provide a rationale why.

3. Definition of problem (5 step process) (PART 1)

• Problem statement

• Root causes

• Stakeholders

• System Boundary Diagram

• Constraints

4. Create a frame diagram of the proposed system (PART 1)

5. Develop a context diagram for the system (PART 1)

6. Create data model (ERD) for your system. In doing so ensure you include all relevant attributes, entities, and relationships. Include appropriate data expressions if where necessary (PART 1)

7. Create a set of representative use cases for the system. (PART 2)

Create a use case diagram showing system boundary, actors, use cases, and relationships.

Then, for a subset of important use cases, create the following;

• Normal scenarios (at least four use cases)

• Augment two of the use cases to consider alternate flows (abormal scenarios)

8. Create Activity diagrams for at least one normal and one abnormal scenario (PART 2)

9. Create Sequence diagrams for at least one normal and one abnormal scenario (PART 2)

10. Develop a data flow diagram for the system (PART 2)

11. Produce a list of Functional Requirements: (PART 2)

12. Produce a list of Non-functional Requirements (PART 2)

13. Create traceability tables showing: (PART 2)

• Use cases are connected to requirements;

14. Quality Attribute Scenarios/Tactics (PART 2)

• Create 2 Quality Attribute Scenarios focusing on addressing meeting non-functional requirements above.

• Select 2 or more tactics to address the Quality Attribute Scenarios and discuss how they will be implemented with level of detail in the context of the software system

15. User Interface Design (PART 3)

1. Develop a low fidelity storyboard of the user interface

2. Create a link table describing how the storyboards bind

3. Develop a low fidelity prototype of the user interface Executable, Suggested C#

16. Class Diagram (PART 3 )

• Create a class diagram for your implementation with methods and data items.

• OO Design Patterns: Extend the class diagram to consider non-trivial object-oriented design patterns (e.g Singleton does not count) and draft interface source file(s) (e.g. Java IFC class or C header file) for your classes 

17. (IN WORK) CM Overview and metrics strategy TBD (PART 3)

• (IN WORK) Develop a Software Configuration Management overview. The CM overview should address:

o TBD

• (IN WORK) Quality Assurance (QA) key metrics that will be collected and rationale.

18. A System level test plan (PART 3)

• Create a System level test plan for the system (using the use cases from earlier). See lecture notes. This is not intended to be something verbose.

• Trace table should be produced mapping requirements to test cases.

19. Glossary (PART 3)

20. Bibliography (PART 3)