software development plan for !! icarus beta release 1.o, v1.0 … · 2015-01-13 · software...

!SOFTWARE DEVELOPMENT PLAN !

FOR !ICARUS !!!

BETA RELEASE 1.O, V1.0 !DECEMBER 17, 2013 !!

Prepared By: !!!Frances Advincula !

Synergy Systems !1234 Main Street !

Columbia, South Carolina 29201 !!!

!

Software Project Manager Program Manager Senior Manager

Configuration Management Quality Assurance Hardware Manager

Systems EngineerIntegrated Logistics Support Test Manager

IV&V Activity Facilities Manager Other Affected Groups

! | F r a n c e s A d v i n c u l a 1

!!This page intentionally left blank. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


!Table of Contents 1. Scope. 6 .....................................................................................................

5. Plans for performing detailed software development activities. 7 .................................

5.3 System Requirements. 7 ...............................................................................

5.3.1 Analysis of User Input. 7 .........................................................................

5.3.2 Operational Concept. 8 ..........................................................................

5.3.3 System Requirements. 10 ........................................................................

5.4 Software Unit Development, Test, and Integration. 11 ..........................................

5.4 System design. 11 ......................................................................................

5.6 Software design. 11 .......................................................................................

5.6.1 CSCI-wide design decisions. 11 .................................................................

5.6.2 CSCI architectural design. 12 ...................................................................

5.7 Software Implementation and Unit Testing. 12 ....................................................

5.8 Unit Integration and Testing. 13 ....................................................................

5.9.3 Preparing for CSCI qualification testing. 14 ...................................................

5.9.4 Dry run of CSCI qualification testing. 14 ......................................................

5.10 CSCI/HWCI Integration and Testing. 15 ..........................................................

5.10.3 Revision and retesting. 15 .....................................................................

5.10.4 Analyzing and recording CSCI/HWCI integration and test results. 15 ...................

5.11 System Qualification Testing. 15 .................................................................

5.11.3 Preparing for system qualification testing. 15 .............................................

5.14 Software Configuration Management 16 .........................................................

5.14. 2 Configuration Control. 16 .....................................................................

5.14. 3 Configuration Status Accounting. 16 ........................................................

5.14.4 Configuration Audits. 16 .......................................................................

5.16 Software quality assurance. 16 ...................................................................

5.16.1 Software quality assurance evaluations. 16 ................................................

5.16.2 Software quality assurance records, including items to be recorded. 17 ..............

5.16.3 Independence in software quality assurance. 18 ..........................................

5.19 Other software development activities. 18 .......................................................

5.19.1 Risk management. 18 ...........................................................................

5.19.2 Software management indicators. 19 .......................................................

6. Schedules and Activity Network. 20 .....................................................................

6.1 Schedules. 20 ...........................................................................................! | F r a n c e s A d v i n c u l a 3

7. Project Organization and Resources. 24 ...............................................................

7.1 Project Organization. 24 .............................................................................

7.2 Project Resources 25 ..................................................................................

7.2.1 Personnel Resources 25 ..........................................................................

7.2.2 Personnel Requirements 26 .....................................................................

7.2.3 Facilities 27 .......................................................................................

7.2.4 Government Furnished Equipment, Software and Services 27............................


!!!!!!!!!!!!!!!!!!!


1. Scope. !1.1 Identification. This Software Development Plan (SDP) details the procedure and strategy to be used in the development of the beta release 1.0 of Icarus, a social networking and analytics web application that will help recruiters and potential hires find each other through levering social data and volunteered information, complete with analytics and reporting for both the perspective of a company and that of an individual candidate. !The beta release 1.0 of Icarus as described in this SDP is part of the overall effort Synergy Systems to leverage into the social networking and big data industries. !1.2 System overview. The purpose of the system is to help companies and candidates whose culture and values align with each other through the use of big data. As we all know, there is a talent war going on the tech industry, as startups and established companies are fighting for the top talent to catapult their organizations into rapid innovation. Icarus’s mission is to do just that: match candidates to companies that reflect their own working style, personality, natural strengths and culture. Icarus shall be built as a secure social web application that supports two perspectives – that of a company and that of an individual user. To accurately predict matches for both perspectives, Icarus would pull in data from social networking sites that the user authorized them to sync with. It will also ask sets of private questions that would help the algorithm assess the user’s personality, likes, dislikes, and competency. Because it will hold sensitive personal and company information, Icarus would have to implement robust security features. To better accommodate a recruiter’s perspective, Icarus would also feature extensive analytics and reporting tools to help them gauge and asses their talent pool tool. From a different point of view, Icarus would also offer reporting to an individual user to help them keep up with employment and educational trends specific to their industry and core strengths. The Beta Release 1.0 of Icarus will be the first product to be developed by Synergy Systems. The entire development process will be conducted at Synergy Systems headquarters in Columbia, South Carolina, United States of America. !1.3 Document overview. This SDP establishes the organization, procedures, and processes Synergy Systems will use to develop Beta Release 1.0 of Icarus. This plan is for internal use only, and is intended to be utilized by Synergy, approved sponsors, and partners to manage the entire development process. This SDP details the project requirements, standards, policies, organizations, schedules, resources, and policies that shall be complied with during the entire development process for Icarus. This SDP complies with the structure of a SDP as outlined DI-IPSC-8127A of MIL-STD-498. !Section 1 covers the scope. Section 5 covers plans for performing details software development including system requirements, software unit development/test/integration, system design, software design, software implementation, unit testing, unit/integration testing, software configuration management, software quality assurance, and other software development activities. !Section 6 covers the schedule, milestones, and activity networks, while Section 7 covers project personnel, resources, and facilities. !1.4 Relationship to other plans. This SDP, along with the documents outlined below, will serve as the guiding documents for the development of Beta Release 1.0 of Icarus: !

• Software Configuration Plan (SCMP) • Software Quality Assurance Plan (SQAP) • Software Configuration Management Plan (SCMP) • Software Risk Mitigation Plan (SRMP) • Software Deployment and Maintenance Plan (SDMP) !


5. Plans for performing detailed software development activities. !5.3 System Requirements. !5.3.1 Analysis of User Input. !To give the team a baseline to build upon for this SDP, the user experience team conducted a pre-analysis of our possible users through interviews and job shadowing. The resulting analysis of user input for Icarus can be seen through use case diagrams illustrated by Figures 5-1, 5-2, and 5-3 below which show interaction between the user and the system from a company user’s perspective, a candidate’s perspective, and a social media site’s perspective respectively. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Figure 5-1. The use case diagram showing a company user’s perspective. !!!!!!!!!!!!!!!!!


!!!!!!! !!!!!!!!!!!!!!!!!!!!

Figure 5-2. The use case diagram showing a company user’s perspective. !!!!!!!!

Figure 5-3. The use case diagram showing the system’s interaction with social media sites. !!5.3.2 Operational Concept. !Icarus operates with two points of views: that of a company recruiter and that of a regular candidate looking for a job. Below are two scenarios that illustrate how each type of user would interact with the system. !From a company’s point of view: Sarah, Technical Recruiter !!Sarah is a tech recruiter for a mid-size company. The research and development team plan to release a new feature to rival a competitor and they have expressed their desire to hire ten more software engineers in the next few months. !Sarah sits at her desk and opens her inbox. There are one hundred emails waiting to be read, resumes submitted from the job ads she had posted. Since those traditionally have the lowest success rates, she filters through emails for referrals from her network or from engineers she had connected with in the last networking event she had gone to. !But Sarah doesn’t always want to tap into her network. All have been living in Silicon Valley and have graduated from the same five schools. She is worried about the dangers of group think and wants to accelerate their levels of diversity. Thus, she heads over to the app and decides to look for people that match the criteria and culture they


are looking for. She sees the search box and the filters that complement the functionality. She plays around with it, and a list displays with the best matches based on the algorithm. !She sees twenty candidates that resonate well with the company. There is a graphic that communicates the level of matching for each of the candidates. She uses it to decide which profiles to look at first. !On each profile, she sees detailed and interactive content, which she enjoys reading. She looks at their profile and enjoys how well she gets to know them before even interviewing them! She sees their videos, past work, and essays, as well as actual metrics on how they fit into the company. !She no longer has to spend precious time researching each candidate in the web – all the work and relevant information are already included in their profiles. !Before the day is over, Sarah looks over the report Icarus generates. She brings up that she noticed there is a surge with the women in tech topic, and the team decides they should reach out to more women in support of Sheryl Sandberg’s Lean In movement. The team agrees the need to ramp up their participation in this, and Sarah volunteers to update their branding pages and data so that potential candidates who value this will readily find them. She uploads a video of a few of their managers who talk about how the company supports work-life balance as well as posted some pictures of the Geek Girl Bay Area Dinners they had hosted a few months back. !!From a user’s point of view: Amanda, About to Graduate and Actively Looking for a Job !!Amanda is an engineering intern at a software company in the Midwest and is about to graduate. However, she has wanted to relocate to Silicon Valley or New York City. She logs into the app and sees the search functionality. She plays around the different filters and looks for companies that value perfection in execution. Several companies result from her search, and clicks on a couple, where she is taken to the company’s branding page. She sees how perfect she is for something like Apple and General Assembly, but probably won’t be a good fit for something like Facebook where they encourage people to “move fast and break things.” !This, she deduced from the essays and videos that were in the branding page. She looks at the jobs they offer and clicks on several. Each job description had a video and a written spread as to what a day in the life of the job is like; it wasn’t a list of bullet points of coma-inducing requirements. She sees that is a good fit for the software engineer job at General Assembly and for the Tech Evangelist job for Apple, all backed up graphics as to why the system recommended this for her. She knows these two companies are going to be tough to get into, so she plans to spend a long time in preparing her application, since she can now focus on the jobs and companies that really fit her well. !She decides to update her profile. She remembered that she just presented a paper, “The Effect of Big Data in Computing”. Thus, heads over to edit her profile which looks like a cross between a portfolio, a magazine spread, and a resume. She adds a PDF to her resume as well as a video of her presenting to the panel. While at it, she collected her other works – websites, journalistic pieces, and includes them in her profile.

!Then Amanda remembers the companies that are giving her offers right now. She searches for them and explores the branding pages. She sees that she is actually a good fit for Cerner, one of the companies that is aggressively pursuing her. !She is looking at her chemistry with the companies, all presented in cool infographics that explain the data analytics, that she decides to answer more questions. She heads to the quiz page, which reminds Amanda of a friendly version of a Myer-Briggs test, but a more professional version of OkCupid’s famous date-related questions. !!


5.3.3 System Requirements. !The requirements to support both a company user’s and a candidate’s interaction with Icarus are outlined below. !

· The system must be able to support a company's viewpoint. !o The company user must be able to view the company profile which includes company name, location,

size, industry, mission, vision, culture, a day in the life. o The company user must be able to edit the company profile. !o. The company must be able to post job descriptions which include job title, job description, a

day in the life of that job, and a personality snapshot. o The company must be able to search by any combination of the following:

· Name !· Location !· Industry !· Level of commitment desired !· Education !· Experience !· Personality type desired !

o. The company user must be able to see a result set of matching candidates which shows candidate name, experience, education, industry, and brief personality summary.

o The company user must be able to view candidate profiles. !o. The company user must be able to see a percentage of how the company matches to with each

candidate. !o. The company must be able to see a report of candidate/industry trends which includes which

candidates are being reached out to the most, a personality summary of candidates the company is getting matched to the most, which companies are trending on twitter. !

· The system must be able to support a candidate's viewpoint. !o. The candidate must be able to view his profile which includes his name, location, !

industry, experience, education, a portfolio, and a personal essay. o The candidate must be able to edit his profile. o The candidate must be able to adjust social media connection permissions. o The candidate must be able to answer personality type questions in the form of a !

question and multiple choice answers. o The candidate must be able to see a result set of matching companies/jobs which

includes the company name, location, industry, and company culture summary, job, job summary, and a day in the life.

o. The candidate must be able to search with any of the following combinations: · Company name !· Job name !· Location !· Industry !· Size !· Time commitment !· Own personal type

o The candidate must be able to view company profiles. !o. The candidate must be able to see percentages of how well he matches with each company/job. !o. The candidate must be able to see a report of companies/industry trends which includes

which companies are being matched to the most. !· The system must be able to pull in data from Tumblr, Facebook, Linked In, and Twitter if a user has

granted permission. !· The system must be able to match companies/jobs to candidates through candidate and !

company personality as determined by the algorithm, competency, education level, experience level, company type, and engagement type. !

· The system must show these match results with a percentage value and a brief summary as to why it ! | F r a n c e s A d v i n c u l a 10

was calculated in that way.

!In addition to the above requirements from a user’s perspective, the system must support the following base functionality crucial to its operating success: !· The system must be able to support state management. !· The system must be able to support authentication of users. !· The system must be able to support authorization of users. !· The system must be able to support localization. !· The system must be able to support error handling. !5.4 Software Unit Development, Test, and Integration.!5.4 System design.!All developers and software architects must participate in system design as outlined in the requirements below.

5.4.1 System-wide design decisions.All developers must formally participate in design sessions at the beginning of each sprint. All decisions made must be recorded in the following.

1. System/Subsystem Design Description (SSDD). Most behavioral, performance, security, etc. decisions that affect the overall system shall be recorded here.

2. Database Design Descriptions (DBDD).

Icarus will follow a “Hybrid of Prototyping and the Incremental Build Model guided by the Scrum Framework for Agile Development” for its development methodology. That means that the team will prototype early to gain user feedback, build the minimum amount of features that solve their problems, deliver, gain more feedback, adjust and deliver again. The requirements for the beta release of Icarus will be spread across ten sprints, with each sprint lasting for 4 weeks.

All design decisions are at left to the developer and software architect unless they are formally converted as requirements stated by the contract.

5.4.2 System architectural design. Software developers and architects shall work together to define and record the architecture of the system. The result shall cover the components of the system, how they interface with each other, as well as how they execute. Those must be recorded in the Systems/Subsystem Design Description (SSDD).

5.6 Software design.!All developers, user experience members, and software architects must participate in software design as outlined in the requirements below.

5.6.1 CSCI-wide design decisions.!All developers and user experience members must formally participate in design sessions at the beginning of each sprint. All decisions made must be recorded in the following.


1. Software Design Description (SDD). Most behavioral, performance, security, etc. decisions that affect individual software components shall be recorded here.

2. Interface Design Description (IDD). Any decisions that pertain to the front-end or the user experience shall be recorded here.

All design decisions are at left to the developer and software architect unless they are formally converted as requirements stated by the contract.

5.6.2 CSCI architectural design.!All developers shall write functional specifications before coding any features in a given sprint. There are no given templates for writing functional specifications (as a reference, see the section Rule 5: Templates considered harmful in Joel Spolsky’s article “Painless Functional Specifications - Part 4: Tips”).

!5.7 Software Implementation and Unit Testing. !!All developers must perform software implementation and unit testing with the requirements as follows. (Note that for the purpose of this section, the term “software” is used to represent programming code and databases.) !5.7.1 Software implementation. Every developer shall build a unit that corresponds to each unit design and specified in the Requirements Document provided in each sprint and outlined in the Requirements Traceability Matrix. This includes design specifications, appropriate code documentation, and database building activities needed to develop the design of the unit. !Note that each software unit does not necessarily have a one-to-one relationship with data entities whether those are stored procedures, database tables, etc. !5.7.2 Preparing for unit testing. All developers must write test cases plans that include inputs, expected outputs, and evaluation criteria needed to properly unit test. Developers must be trained in Test Driven Development, and must follow the following TDD rules at all times: !

• Write a failing test before you write production code. • Write just enough for the unit test to fail. !• Write just enough production code to make the test pass.

!5.7.3 Performing unit testing. Developers must write at least one unit test per software unit built. The entire code base must have an overall code coverage of 80% at any given point. One hundred percent of all C# tasks must have a unit test. All unit tests should have 75% code coverage for that unit before it is committed to the code repository. To measure code coverage for the .NET side, NDepend shall be used. For the JavaScript side, LCOV and GCOV shall be used. !For the back-end, developers must use Visual Studio Ultimate's Performance testing framework. Moles can be used for those hard to test cases. !!The following are the tools that shall be used to unit test the front-end of the system. !Assertion Framework:


!Jasmine is widely used by most JavaScript developers for unit testing. It is open source and uses the MIT license. It hooks in to most, if not all, of the JavaScript Test Runners. It is based on the RSpec definition. !!Mock Type Tools: !Ext Spec 1.0.2 Ext Spec is a toolset that isolates the ExtJs classes for unit testing with frameworks like Jasmine and QUnit. It eliminates the need to test the ExtJs framework and allows developers to focus on the application unit testing instead. It handles the ExtJs framework for the developer and removes the need to include the ExtJs framework for the tests. It is similar to a mock library for c# code. It uses the Apache license. !!JavaScript Test Drivers: JS Test Driver is a test driver that integrates with continuous build systems and runs tests on multiple browsers quickly to ease TDD style development. It has command line control, parallel test executions, fast tests, full control of DOM, easy configuration, and code coverage. It uses the Apache 2.0 license. !!!5.7.4 Revision and retesting. The developer shall revise and refactor each software unit as deemed necessary to develop robust, maintainable software that adheres to SOLID principles. For junior developers, 100% of code must be reviewed before committing into the repository. Senior developers and architects are encouraged to do so. !Each weekly review will hold a code walkthrough for all software units finished during the week. Monthly code reviews include a code inspection and a solution review to be done by an architect. !5.7.5 Analyzing and recording unit test results. All developers shall update code comments and documentation based on changes made due to code reviews, inspections, and walkthroughs. Analysis of unit tests shall be recorded in the appropriate software development file (SDF).

5.8 Unit Integration and Testing. !All developers must perform integration testing. Two or more software units must be covered by an integration test for it to be acceptable. !5.8.1 Preparing for unit integration and testing. If a developer is testing interfaces to third-party software, in this case different social media sites such as Facebook, Linked In, Twitter, appropriate environments such as test servers must be set up as necessary. Complete documentation, including but not limited to inputs, expected results, acceptance criteria, and testing standards must be established and recorded in the appropriate software development file (SDF). An Integration Test Plan/Procedures (ITP/P) shall detail that criteria that tests plan must cover, including the following: !

1. Requirements traceability 2. Requirements consistency (internal and external) 3. Test coverage 4. Conformance to expected results 5. Test maintenance 6. Test feasibility !


5.8.2 Performing unit integration and testing. Since we are creating the beta release of Icarus, a bottoms-up approach will be utilized for integration testing so testing can start as early as possible. This means lower levels will be tested, especially against test servers for connection points, as units are completed. !5.8.3 Revision and retesting. As defects are discovered, they shall be entered in the bug/task tracker the team is utilizing, in this case, Pivotal Tracker. They must be addressed by the developer and once fixed, the units in the integration tested must be completely retested according to the test cases and procedures established. !5.8.4 Analyzing and recording unit integration and test results.All analysis of metrics collected and recorded must be documented in the appropriate software development file (SDF) and in a comprehensive Integration Test Report (ITR). !5.9 CSCI Qualification Testing. In contrast to integration testing as outlined in Section 5.8, CSCI qualification testing shall be done by the Quality Control team. This decision to distinguish between the two was made to eliminate redundancy in testing, since Icarus is a new project without the complexity seen in most systems that do utilize CSCI qualification testing. However, we already wanted the practice to be set in place to be ready for the time when Icarus does mature to that level of complexity.

5. 9.1 Independence in CSCI qualification testing. Each configuration item equates to a feature set that work as a whole. The QC that tests each CI shall not be the developer or author of the design document of those feature sets.

However, there is no limitation in the QC communicating to the developers of that feature set.

5.9.2 Testing on the target computer system. CSCI testing must be done in environments that mimic a user’s, and not a development environment.

5.9.3 Preparing for CSCI qualification testing. !The QA resource performing the testing must detail testing plan and procedures in a Software Test Description (STD).

5.9.4 Dry run of CSCI qualification testing. All developers must ensure they provide the QC resource with all the setup and data needs required.

5.9.5 Performing CSCI qualification testing.

The QC resource shall perform CSCI testing according to testing standards as outlined in the Software Quality Management Plan (SQMP) and the STD in a production, real-world environment.

5.9.6 Revision and retesting.

As defects are discovered, they shall be entered in the bug/task tracker the team is utilizing, which in this case is Pivotal Tracker. They must be addressed by a developer and once fixed, the CI must be manually tested again.

5.9.7 Analyzing and recording CSCI qualification test results. ! | F r a n c e s A d v i n c u l a 14

All analysis of metrics collected and recorded must be documented in the appropriate software development file (SDF) and in a Software Test Report (STR).

5.10 CSCI/HWCI Integration and Testing. !Icarus is a software product, specifically a website to be accessed online. This section is not applicable.

5.10.1 Preparing for CSCI/HWCI integration and testing.

Not applicable.

5.10.2 Performing CSCI/HWCI integration and testing.

Not applicable.

5.10.3 Revision and retesting. !Not applicable.

5.10.4 Analyzing and recording CSCI/HWCI integration and test results. !Not applicable.

5.11 System Qualification Testing. !The Quality Control team shall take responsibility to perform system qualification testing to ensure that all system requirements have been met.

5.11.1 Independence in system qualification testing.

Any Quality Control resource assigned to perform system qualification testing should not be part of any design decisions of the system to keep testing and reporting as objective as possible.

5.11.2 Testing on the target computer system.

System Qualification testing must be done in environments that mimic a user’s, and not a development environment.

5.11.3 Preparing for system qualification testing. Any Quality Control resource must review the general system requirements in tandem with the Software Quality Management Plan (SQMP).

5.11.4 Dry run of system qualification testing. Since the system qualification testing is not to be performed by an acquirer at this scenario, all system qualification testing must be done in an environment that mimics that of a user as outlined in 5.11.2.

5.11.5 Performing system qualification testing. In contrast with CSCI Qualification Testing where each module is tested within the context of itself, system qualification testing tests the system as a whole, just like how a user would use it in a real world scenario.

5.11.6 Revision and retesting. As defects are discovered, they shall be entered in the bug/task tracker the team is utilizing, which in this case is


Pivotal Tracker. They must be addressed by a developer, and once fixed, the CI must be manually tested again. More importantly, since the goal of system qualification testing is to test the system as a whole in a real world environment, system qualification testing shall be re-performed once the testing for that particular CI has passed.

5.11.7 Analyzing and recording system qualification test results. All analysis of metrics collected and recorded must be documented in the appropriate software development file (SDF) and in a Software Test Report (STR).

5.14 Software Configuration Management !The development of Icarus will utilize technical standards and administrative procedures throughout the software development life cycle to identify software units and control modifications made to the code base as referenced by the Software Configuration Management Plan (SCMP). Team City will be used for Continuous Integration, while Tortoise SVN will be used as the code repository. !Furthermore, a release manager will oversee configuration management and will oversee the release lifecycle of Icarus following the requirements specified in the following paragraphs. !5.14.1 Configuration Identification. Most larger projects have a Software Configuration Control Board (SCCB) that manages configuration activities. However, due to the team size of Icarus, a release manger will be responsible to identify and document each configuration item and its version. !5.14. 2 Configuration Control. !All software units are baselined according to code standards and code reviews. Changes to baselined units will be noted by the developer in each task in Pivotal Tracker, as well as noted in the description when they commit. Furthermore, it will also be identified and documented by the release manager. Team City and Tortoise SVN will be used as the build tracker and code repository respectively, while Microsoft SharePoint will be used to manage documents. !5.14. 3 Configuration Status Accounting. !The release manager must be able to provide full records, logs, and reports to show status of each controlled item at any given point. TeamCity and Tortoise SVN alone should provide in-depth data of change history. A review will be conducted at each sprint retrospective which is held before the start of a new sprint. !5.14.4 Configuration Audits. !The release manager shall formally make master copies of code and all documentation by tagging each branch in the code repository. !5.16 Software quality assurance. !The overall software quality of Icarus will be based on a three phase approach consisting of Quality Planning, Quality Assurance, and Quality Control.

5.16.1 Software quality assurance evaluations. During Quality Planning, we will take the following organizational process assets and project requirements to come


up with a Quality Management Plan (QMP) and a Quality Baseline (QB, consisting of scope, cost, and schedule) for Icarus:

!Synergy Systems

• Coding and performance standards • Quality policies, procedures, and guidelines • Lessons learned from previous projects • Company culture about quality !

Project Requirements

• Scope • Deliverables • Acceptance Criteria • Project Contract • Thresholds !

Quality should be balanced with scope, time, budget, performance, risk, resources, and customer satisfaction in mind. To come up with the standards in the QMP and the QB, we will be using a cost-benefit analysis, a cost of quality, and benchmarking techniques as well.

!During the Quality Assurance phase itself, we shall take the QMP, quality metrics, work performance information, and quality control measurements to help us execute the following tools and techniques in evaluating and performing quality assurance:

Quality Audits

• Code Reviews – Should happen anytime a junior developer has to commit code into the code repository. It can be done either through email, the code review tool (such as Review Board or SmartBear), or in-person.

• Solution Reviews – Should happen every quarter. A software architect from another team shall inspect the design and overall code cleanliness. A document of the solution review results shall be presented, and every item raised must be addressed by the development team.

• User Acceptance Testing – Should happen at the start of every sprint, or every time a new feature is introduced.

Continuous Improvement through Process Analysis

• Sprint Retrospectives – Before the next sprint starts, a retrospective of the whole development process must be held so the team can look at ways they can improve the whole process and learn from mistakes, as well as come up with best practices. !

During the Quality Control Phase, the team should utilize Inspection, Manual Testing, and Defect Repair and Re-Inspection to ensure that all deliveries are up to standards. !5.16.2 Software quality assurance records, including items to be recorded. !The following items are the outputs in each phase of quality management: !


Quality Planning Phase

o Quality Management Plan o Quality Baseline !

Quality Assurance Phase

• Process Updates in Assets • Change Requests • Updates the QMP and Project Documents !

Quality Control

• Quality Control Measurements • Validated Changes • Validates Deliverables • Change Requests !

Quality Metrics should be kept track of in a Quality Report and visually represented in the following charts: !• Flowchart • Histogram • Pareto chart • Run chart • Scatter Diagram !

!5.16.3 Independence in software quality assurance. !The persons who evaluate the software quality shall not be the same people who developed or created the product. Evaluators should not be responsible for any activity or deliverable in the software product. The evaluators do have the resources and full authority and freedom to conduct objective evaluations; they also have full responsibility to make sure that corrective actions are taken if necessary.

5.19 Other software development activities. !5.19.1 Risk management. !Below outlines key risks for the development of Icarus. These risks will be tracked by the Project Manager and will be discussed as seen relevant in each scrum meeting and sprint review. !1. Requirements Stability: If the number of new features requested exceeds 6, we will experience cost and schedule slippage with our difficulty to maintain stable requirements. !Metrics: The more companies and individual candidates we involve, the more features will be wanted, the more we will discuss, etc. This all leads to cost and schedule slippage. !Risk Prevention Plan: Use a requirements traceability matrix to manage requirements: new, changed, deleted, original, everything. !Contingency Plan: Encourage communication of requirements and feedback gathered in daily scrum meetings. !


Entrance Criteria: Reduce functionality to a workable beta product as agreed by team. !2. New Technology: If less than 80% of our team members have built commercial software using any JavaScript framework, our development team will lag behind due to an initially steep learning curve for the chosen JavaScript framework, ExtJS, has a steep initial learning curve. !Utilize Sencha (owner of ExtJS) services team, whose sole purpose is to help developers who code using their API. !Metrics: Count each team member that is proficient in ExtJS and plain old JavaScript. !Risk Prevention Plan: Provide ExtJS training including, but not limited to, tutorials, guides, hands-on intensives and bootcamps. !Contingency Plan: Use and enforce clean coding standards, unit testing, and behavior-driven development. !Entrance Criteria: Eighty percent of team members have never shipped a product utilizing ExtJS. !3. Social Media Integration: If Social Media Sites are reluctant for us to use their data, our algorithm will not have enough data sets to be accurate. !Metrics: Track the number of social media sites that are willing to partner with us. !Risk Prevention Plan: Have an aggressive business development team that will outline the benefits for THEM. !Contingency Plan: Utilize one of their main competitors. For example, if Tumblr declines to partner with us Icarus, the team can utilize a willing competitor such as Wordpress or other blogging platforms. !!Entrance Criteria: We fail to integrate with the top 3: Facebook, Twitter, and LinkedIn. !!!4. Perils of Agile Teams: If our team is unaware of common mistakes agile teams make (such as group think or the Abiline Paradox Syndrome -- private decision making), we will not be able to make as innovative a product and development time will increase as decisions made about what needs to be worked on are not communicated effectively. !Metrics: Track how often requirements change. Track how often an idea is challenged during a sprint planning. !Risk Prevention Plan: Hold an onboarding workshop on the topic with specific action items. Remind team on a regular basis. Hold sprint retrospectives. !Contingency Plan: Left up to the project manager.

!5.19.2 Software management indicators.

The project manager, in tandem with developers, shall use the software metrics below to track the software development process as well as communicate the progress of the project. The following software metrics must be kept track off and reported in the proper medium to the proper channels as deemed appropriate by the project manager:

• Requirements volatility. The total number of requirements and how they have changed, if applicable over time.

• Software size. The total number of planned and actual lines of code. ! | F r a n c e s A d v i n c u l a 19

• Software staffing. The resources allocated to the project over time, including staff turnover rates.

• Unit test coverage. The number of software modules covered by a unit test.

• Software progress. The total number of requirements that are designed, coded, unit tested, implemented, etc. over time as specified in the SDP and its changes/revisions in the configuration tool, such as Microsoft SharePoint as outlined in the SCMP.

• Effect of reuse. The number of modules that were able to be reused or are candidates for reuse, whether or not some need modification and the level of modification required.

• Build release. The total numbers of coded features or modules released in each build.

• Scrap/rework. The total number of coded features or modules that fail code review or solution review and thus needs to be redone.

• Quality. Total count of bugs, as well as their state (open, fix in development, pending build, etc.), severity level, priority level. Total count of bugs resolved.

• Software Maturity. The mean time between system failures and the number of bugs found per execution time.

• Schedule. Information and tracking of start and end of tasks and milestones as scheduled. • Cost. Information and tracking of budget, cost drivers such as development, tests, and maintenance costs. • Capacity. Tracks performance of the system during production including system speed and throughput. !

6. Schedules and Activity Network. !6.1 Schedules.!The Task Breakdown and Schedule for the Beta Release of Icarus is shown below in Table 6.1; it indicates an intensive development schedule that includes the team having to work throughout the traditional holiday season as observed in the United States. The reason is that Synergy Systems is aiming to go live with a complete, fully functional version of Icarus by May 2014 in order to capture the market of new graduates as they as they try to enter the workforce. Therefore, Synergy Systems is dedicated to complete the beta release by January so that full customer validation and more user research can be obtained.

All milestones (marked in all capitals in the table) should be tracked during the appropriate design review (see 5.4 and 5.6) and test readiness review (see 5.11.3 Preparing for system qualification testing) which are included in a sprint retrospective, code reviews (see 5.7.4 Revision and retesting), and solution reviews (5.16.1 Software quality assurance evaluations).

ID Task Name Duration Predecessors Start Finish

0 Icarus Beta Release 47 days Mon 11/25/13 Fri 1/10/14

1 Requirement Gathering/Analysis 7 days Mon 11/25/13 Tue 12/3/13

2 Conduct User Research 5 days Mon 11/25/13 Fri 11/29/13

3 Create Project and Scope Documents 2 days 2 Mon 12/2/13 Tue 12/3/13

4 REQUIREMENTS ANALYSIS COMPLETE 0 days 3 Tue 12/3/13 Tue 12/3/13

5 Solution Design 11 days 4 Wed 12/4/13 Wed 12/18/13


6 Design Website Site-map 1 day 4 Mon 12/9/13 Mon 12/9/13

7 Create Website Site-map Document 1 day 4 Wed 12/4/13 Wed 12/4/13

8 Create Wireframes 2 days 7 Wed 12/11/13 Thu 12/12/13

9 Create Back-end Solution Diagrams 3 days 7 Thu 12/5/13 Fri 12/13/13

10 Create Database Schema 2 days 9 Tue 12/17/13 Wed 12/18/13

11 SOLUTION DESIGN COMPLETE 0 days 10 Wed 12/18/13 Wed 12/18/13

12 UX Design 6 days 11 Thu 12/19/13 Thu 12/26/13

13 Design Home, Contact Us, About Us, etc. Interfaces 2 days 11 Mon 12/23/13 Tue 12/24/13

14 Design Search Interface 2 days 11 Wed 12/25/13 Thu 12/26/13

15 Design Social Components Interfaces 2 days 11 Thu 12/19/13 Fri 12/20/13

16 Design Quizzes Interfaces 2 days 11 Fri 12/20/13 Mon 12/23/13

17 Design Profile Management Interfaces 1 day 11 Thu 12/19/13 Thu 12/19/13

18 UX DESIGN COMPLETE 0 days 17 Thu 12/19/13 Thu 12/19/13

19 Font-end Development 11 days 18 Fri 12/20/13 Fri 1/3/14

20 Develop Home, Contact Us, About Us, etc. Interfaces 3 days 18 Wed 12/25/13 Fri 12/27/13

21 Develop Basic Search Interface 1 day 18 Mon 12/30/13 Mon 12/30/13

22 Develop Advanced Search Interface 3 days 18 Tue 12/24/13 Wed 1/1/14

23 Develop Trending Section Interface 2 days 18 Thu 1/2/14 Fri 1/3/14

24 Develop Social Stream Components 2 days 18 Fri 12/20/13 Mon 12/23/13

25 Develop Candidate Profile Components 3 days 18 Fri 12/20/13 Tue 12/24/13

26 Develop Company Profile Components 1 day 18 Fri 12/20/13 Fri 12/20/13

27 Develop Quizzes Interface 3 days 18 Fri 12/20/13 Tue 12/24/13

28 FRONT-END DEVELOPMENT COMPLETE 0 days 27 Tue 12/24/13 Tue 12/24/13

29 Back-end Development 40 days 18 Fri 12/20/13 Thu 2/13/14

30 Develop Search Module 14 days 18 Wed 1/15/14 Thu 2/13/14

31 Develop Profile Management Module 14 days 18 Fri 12/20/13 Wed 1/8/14

32 Develop Matching Algorithm Module 28 days 18 Fri 12/20/13 Tue 1/28/14

33 Develop Data Mining Module 7 days 18 Fri 12/20/13 Mon 12/30/13

34 Develop Social Module 4 days 18 Fri 12/20/13 Wed 12/25/13

35 BACK-END DEVELOPMENT COMPLETE 0 days 34 Wed 12/25/13 Wed 12/25/13

36 Testing 6 days 35 Thu 12/26/13 Thu 1/2/14


!Table 6.1. Icarus Project Schedule

37 Perform Internal Testing (Functional/Security) 5 days 35 Thu 12/26/13 Wed 1/1/14

38 Perform Functional Testing 3 days 35 Thu 12/26/13 Mon 12/30/13

39 Perform System Testing 3 days 35 Thu 12/26/13 Thu 1/2/14

40 Perform User Acceptance Testing 3 days 35 Thu 12/26/13 Mon 12/30/13

41 Re-test modified code 2 days 35 Thu 12/26/13 Fri 12/27/13

42 TESTING COMPLETE 0 days 41 Fri 12/27/13 Fri 12/27/13

43 Implementation 12 days 41 Mon 12/30/13 Tue 1/14/14

44 Perform Miscellaneous Deployment Activities 5 days 42 Mon 12/30/13 Fri 1/3/14

45 Set up Database and Upload Files 2 days 44 Mon 1/6/14 Tue 1/7/14

46 Modify code 3 days 45 Wed 1/8/14 Fri 1/10/14

47 Re-test modified code 2 days 46 Mon 1/13/14 Tue 1/14/14

48 IMPLEMENTATION COMPLETE 0 days 47 Tue 1/14/14 Tue 1/14/14

49 Documentation 4 days 35 Thu 12/26/13 Tue 12/31/13

50 Develop Help specification 1 day 35 Thu 12/26/13 Thu 12/26/13

51 Review all user documentation 2 days 35 Thu 12/26/13 Fri 12/27/13

52 Incorporate user documentation feedback 2 days 51 Mon 12/30/13 Tue 12/31/13

53 DOCUMENTATION COMPLETE 0 days 52 Tue 12/31/13 Tue 12/31/13

54 Deployment 5 days 53 Wed 1/1/14 Tue 1/7/14

55 Determine final deployment strategy 1 day 53 Wed 1/1/14 Wed 1/1/14

56 Develop deployment methodology 1 day 55 Thu 1/2/14 Thu 1/2/14

57 Secure deployment resources 1 day 56 Fri 1/3/14 Fri 1/3/14

58 Train support staff 1 day 57 Mon 1/6/14 Mon 1/6/14

59 Deploy software 1 day 58 Tue 1/7/14 Tue 1/7/14

60 DEPLOYMENT COMPLETE 0 days 59 Tue 1/7/14 Tue 1/7/14

61 Post Implementation Review 3 days 60 Wed 1/8/14 Fri 1/10/14

62 Document lessons learned 1 day 60 Wed 1/8/14 Wed 1/8/14

63 Distribute to team members 1 day 62 Thu 1/9/14 Thu 1/9/14

64 Create software maintenance team 1 day 63 Fri 1/10/14 Fri 1/10/14

65 POST IMPLEMENTATION REVIEW COMPLETE 0 days 64 Fri 1/10/14 Fri 1/10/14

66 SOFTWARE DEVELOPMENT COMPLETE 0 days 65 Fri 1/10/14 Fri 1/10/14


6.2. Activity Network.

An activity network for the Beta Release of Icarus is shown below in three parts, in Images 6.2.A, 6.2.B, and 6.2.C

!

!

!

!

!


Image 6.2.B. Icarus Activity Network Part 2

Image 6.2.A. Icarus Activity Network Part 1

!

!!!7. Project Organization and Resources. Synergy Systems technologies is composed of different departments that support a software development cycle. Below is a breakdown of how different departments support the development of Icarus. !7.1 Project Organization. The project organization for the Icarus is shown below in Figure 7-1. Note that the Quality Control team is not part of the Icarus Team itself, but is part of the larger Synergy Systems. That way, as time constraints loom in, performance and quality control measures remain objective. !

! Figure 7-1. Organization for Icarus !

The roles and their description can be seen in Table 7-1 below. !Role Responsibility

Company (user) Participates in beta testing and user experience research


Image 6.2.C. Icarus Activity Network Part 3

!!7.2 Project Resources

7.2.1 Personnel Resources The staff load balance is shown in table 7-2. A full cost and effort estimate with a complete Work Breakdown Structure (WBS) is in Appendix B. !

Candidates (user) Participates in beta testing and user experience research

Synergy Systems Oversees project development, funds and sponsors project

Project Manager Interacts with business side to and translates market needs to product requirements; communicates product requirements to technical teams

User Experience Manager Oversees both documentation and user experience/research actives

Technical Writer Documents project activities and diagrams; writes manuals/FAQ for users of system

User Experience Designer Researches and designs interaction of users with system

Software Engineering Manager Oversees all software development lifecycle activities; create and oversee software development plan

Software Engineering Team Create design diagrams for features; create, maintain, and test code for features; support test and delivery

Quality Control Manager Oversees all testing and quality assurance effort

Quality Control Team Execute all testing and quality control efforts; ensures all deliveries satisfy customer requirements and are free of defects


! !!!!7.2.2 Personnel Requirements !Personnel Requirements for Icarus are outlined in Table 7-2-B.

Role Requirements

Project Manager Minimum 10 years in managing software teams. Impressive portfolio of products shipped. BS in Computer Science and an MBA preferred.

User Experience Manager Minimum 5 years’ experience in managing user experience, extensive user research, portfolio of successful products designed, MS in Human Computer Interaction

Technical Writer Minimum of 3 years’ experience in writing technical documentation.

User Experience Designer Portfolio of products designed, mastery of Adobe Creative Cloud, Axure, and Balsamiq mockups.

Software Engineering Manager Minimum 5 years’ experience in managing software teams. Mastery of full stack programming, C# backend and JavaScript frontend preferred. BS in Computer Science required, MS in Computer Science preferred.


Table 7-2-B. Personnel Qualification Requirements for Icarus !7.2.3 Facilities !All user experience and research will be conducted at participating companies’ and users’ home locations. All design, development, and testing efforts for Icarus will be held at the headquarters of Synergy Systems located in Columbia, South Carolina. !7.2.4 Government Furnished Equipment, Software and Services !No Government Furnished Equipment, Software, and Services will be used in the development of Icarus by Synergy Systems.

Software Engineering Team Minimum 3 years’ experience in programming for team members and 5 years for lead engineers. Mastery of full stack programming for team leads, C# and .NET experience for backend engineers, and JavaScript experience for frontend engineers required. BS in Computer Science required.

Quality Control Manager Minimum 5 years’ experience in managing quality control teams. Mastery of test automation required. Product support experience preferred.

Quality Control Team Minimum 3 years’ experience in scripting for test automation.
