You are on page 1of 8

The organization is involved in automating their order processing system. Integrating with the printing machine is a critical part in this project and no one has done a similar integration earlier. you should be able to. You are given 1 business analyst. Assessment criteria: (Total 100%) • • • • • • Preparation of Work Breakdown Structure (WBS) 20% Listing of risks involve in this project 20% Drawing of grant chart 20% Planning suitable requirement gathering techniques 20% Report presented using a word processing software (e. Also once an order is processed the machine will update the system automatically. Except for one software engineer others have not done similar kind of project and neither do you have any experience in handling this kind of automation project. The proposed system should be able to connect with their newly purchased high tech printing machine and it will automatically provide the status of each order. The owner plans to get large orders from some companies to print their annual reports. MS Word) 10% Formatting of the Report 10% . You need to gather requirements and develop a computer system in order to automate the said organization. 2 software engineers and 3 trainee software engineers. • • • Identify Work Breakdown Structure Draw a project plan Analyze and document project risks Problem: You are hired as a project manager to handle a project at a printing organization. The project owner is the CEO of the organization he has no IT experience and users in this organization have not worked in an automated system.Assignment 01 Starting week: 06 Due Week: 08 Assignment Goals: On completion of this assignment. The required system needs to handle customer orders placed by the customer care officers and those placed orders are processed by back office staff. Training should be given to 3 trainee software engineers in order to get output from them.g. He applies pressure to finish the project within 6 months.

"Obtain approvals to proceed (concept.1. Test component modules to product specifications 5.9.4. timeline.6. Develop integration test plans using product specifications Develop preliminary budget 2. Conduct needs analysis 2. Unit Testing 5.3. Develop code 4. Review modular code Obtain approval to proceed 3.2.1. Develop unit test plans using product specifications 5. Identify anomalies to product specifications . Design complete 4.Cost Estimation and Cost Benefit Analysis 1. Preparation of Work Breakdown Structure (WBS) 20% 1.1. budget)" 2.4. Review preliminary software specifications 3. Develop delivery timeline 2.2. Identify modular/tiered design parameters 4.3.5. Developer testing (primary debugging) 4.2. Review software specifications/budget with team 2. Draft preliminary software specifications Secure required resources 2. Incorporate feedback on software specifications 2. Development 4.2. Develop functional specifications 3. Development complete 5. Testing 5. Scope complete 2. Determine project scope 1.3. Incorporate feedback into functional specifications Scope 1. Review functional specifications 3. Secure core resources 1. Proposal Writing 1.3. Develop prototype based on functional specifications 3.5. Analysis/Software Requirements 2.5. Design 3. Assign development staff 4. Review functional specifications 4. Analysis complete 3.2.6.

Training materials complete 7. Incorporate Help documentation feedback Determine final deployment strategy 9.2. Develop training delivery mechanism 6. Pilot Review Help documentation 7.6. Integration testing complete 6.)" 6.1.2. Conduct training usability study 6.7.1. Unit testing complete 5. Evaluate testing information 8. Re-test modified code 5. Identify anomalies to specifications 5. Secure deployment resources 9. Develop training specifications for helpdesk support staff 6. Install/deploy software 8. Incorporate user documentation feedback 7. Re-test modified code 5.4. Deploy software 9.6.4. Modify code 5. Test module integration Obtain user feedback 8. Deployment 9.5. Review all user documentation 7. Documentation complete 8.1. Develop Help specification 7.5. Deployment complete . Modify code 5. Develop deployment methodology 9. Integration Testing 5.3. Develop user manuals specifications 7.8.3. classroom.6. Identify test group Develop training specifications for end users 6. Training 6.4.6. Develop training materials 6. Train support staff 9. Finalize training materials 6.9. Develop Help system 7. Develop user manuals 7. Pilot complete 9.3.2. etc. Develop software delivery mechanism 8. "Identify training delivery methodology (computer based training.4.1. Documentation 7.4.

5. skills of individuals etc.3.4. . Distribute to team members 10.Specification Breakdown When coding and integration begin it becomes apparent that the specification is incomplete or contains conflicting requirements. Unexpected project scope expansions.Requirements Inflation As the project progresses more and more features that were not identified at the beginning of the project emerge that threaten estimates and timelines. 3. Software development template complete 2. 6.1. Cost overruns Project scope expansion 7. 2. the sense of urgency to work in earnest is often absent resulting to time lost in early project stages that can never be regained. Failure to identify complex functionalities and time required to develop those functionalities. failed system or some external events risks.5. Post Implementation Review 10. given the intangible nature and uniqueness of software. Create software maintenance team 10.10.Operational Risks: Risks of loss due to improper process implementation.Employee Turnover Key personnel leave the project taking critical information with them that significantly delays or derails the project. Listing of risks involved in this project 20% 1. 4.Inherent schedule flaws Software development.2. Wrong time estimation Resources are not tracked properly. Post implementation review complete 10.Poor Productivity Given long project timelines. is inherently difficult to estimate and schedule. systems. All resources like staff.Budget Risk Wrong budget estimation. Document lessons learned 10.

Project file Name: Software Development. Planning suitable requirement gathering techniques 20% 1.Causes of Operational risks: Failure to address priority conflicts Failure to resolve the responsibilities Insufficient resources No proper subject training No resource planning No communication in team. Market development Changing customer product strategy and priority Government rule changes.Programmatic Risks: These are the external risks beyond the operational limits.Technical risks: Technical risks generally leads to failure of functionality and performance. Difficult project modules integration. Causes of technical risks are: Continuous changing requirements No advanced technology available or the existing technology is in initial stages. In this project. These are all uncertain risks are outside the control of the program. 3. it helps to identify possible solutions to Machine Integration problem. Drawing of grant chart 20% Please see Ms. . 8. 9.mpp 4. Brainstorming casts a wide net. and clarify details of opportunities. Brainstorming Brainstorming helps in requirements elicitation to get as many ideas as possible from a group of people. Product is complex to implement. These external events can be: Running out of fund.

5. Prototyping Prototypes can be very effective at gathering feedback. Without understanding the goals and expectations of the users and stakeholders. 6.Document Analysis Reviewing the documentation of an existing Manual system can help when creating Process documents and Designing the system. We also have to recognize the perspective of each interviewee. pain points and opportunities for improvement.Focus Group A focus group is a gathering of people who are representative of the users or customers of a product to get feedback. Either approach can be used to uncover implicit requirements that otherwise might go overlooked. they can quickly assess if a design approach would . The feedback can be gathered about needs / opportunities / problems to identify requirements. would even be reviewing the requirements that drove creation of the existing system – a starting point for documenting current requirements. or can be gathered to validate and refine already elicited requirements. an analyst can identify a process flow. By observing users. Observation The study of users in their natural habitats is what observation is about. Prioritization of those possibilities is important to finding the needles in the haystack. Interview Interviews of stakeholders and users are critical to creating the great software. Passive observation is better for getting feedback on a prototype (to refine requirements). where active observation is more effective at getting an understanding of an existing business process. Often.identifying many different possibilities. 3. we are very unlikely to satisfy them. Nuggets of information are often buried in existing documents that help us ask questions as part of validating requirement completeness. so that we can properly weigh and address their inputs. 4. awkward steps. Observation can be passive or active (asking questions while observing). Low fidelity prototypes can be used as an active listening tool. when people can not articulate a particular need in the abstract. 2.

7. or have open ended questions allowing free-form responses.address the need. Survey design is hard – questions can bias the respondents. Survey When collecting information from many people – too many to interview with budget and time constraints – a survey or questionnaire can be used. Thank you. . The survey can force users to select from choices. rate something (“Agree Strongly. Agree…”). Prototypes are most efficiently done with quick sketches of interfaces and storyboards.