UNIT TWO

PROGRAM LOGIC DOCUMENTATION

 2.1 Project planning standards
Project planning standards are set to attain the project goals. Project planning standards may obviously vary from project to
project, but the goals are usually the same to complete the project within the timeframe and without exceeding the allotted
resources.
 Setting Standards for Project Management and the Creating Project Plan
Project planning standards should be able to clearly define general project activities and address the specific requirements of
individual projects.
The project standards should provide adequate details to ensure all team members can identify project objectives and relate to its
fulfillment.
Project planning standards must take into account the overall project management system, its merits and limitations, define goals
of the project, organize the information system with easy identification of project objectives and also plan for bridging a system
network to monitor and control the projects efficiently.
 Project Planning Standards - Parameters and Applications
Project planning standards, for them to be true to definition, should include features, such as:
 Quality Assurance Necessities
 Risk Management Plan
 Security Measures
 Testing Techniques
 Documentation and Portfolio Requirements
Project planning standards should also include configuration management standards aimed at minimizing
disruptions affecting a project management system and ensuring smooth flow of project progress.
Audit and compliance authorities should assist quality assurance personnel to verify, at every stage, conformity of
project requirements (internal or external). Project scalability varies from project to project.
2.2 Documentation of Project scope
The larger the project, the more important it becomes to use CASE tools in the software's development.
The purpose of a scope and limitations statement is to provide an outline of what your project will address and what
it won’t address. What you turn in will include the following:
 a description of the project (what technology you are addressing and the rationale for choosing that technology),
 an explanation of what kind of data you will collect, the methods you will use (interviews, library research, observation,
etc.), and how much of each kind of data you will collect,
 an explanation of how you are approaching the challenge of making something ‘better’ (making it less expensive, easier
to use, available to a more diverse population, more environmentally friendly, etc.),
 A proposal about how you will test your initial design suggestions. Remember the design guidelines provided during
Unit 1, and address these as you outline your approach
 A timeline with major tasks to be accomplished for the project and which team member will take a leadership role and
responsibility for the task.
A project scope document sometimes called a scope of work (SOW) is a critical piece of project paperwork that gets teams
and stakeholders aligned on the boundaries of a project before it even begins.
A well-defined scope document can save you from major headaches by defining the following project elements:
 Project goals
 Requirements
 Major deliverables
 Key milestones
 Assumptions
 Constraints

2.3 Project scope statement

A scope of work (SOW) document is an agreement on the work you're going to perform on the project.
The document includes it's a section of the document that delineates the major phases across the schedule of the project's
duration.
There are lots of different ways to write a scope statement.
 The list of possible elements you should consider adding to your project scope statement.
 Business case and goals: Every project has goals, and this is where you’ll define them. This typically includes the reasons
the project is being supported (or funded), along with a set of business goals or intended project outcomes for your team to
keep in mind while executing the project.
 Project description and deliverables: This is a plain language overview of the project’s deliverables. Avoid confusion by
clearly outlining what will be delivered for approval through the course of the project, as well as the final deliverable.
 Acceptance criteria: Your scope should help you come to an agreement on what will be delivered and leave no question
when the project is complete. Acceptance criteria can be measured, achieved, and used to prove that work is complete.
 Limitations: Every project has its limits, and you need to be sure you’re not exceeding those limits to complete a project on
time and under budget.
Limitations can come in many forms, but one example would be technology. For instance, if you’re building an application that
depends on a specific technology, be sure to mention that.
 Assumptions: You know what they say about assumptions, and you probably know it’s true. If you don’t outline them,
you’ll end up with confusion, missed expectations, and project problems.
 Exclusions: You’ve already listed out the deliverables you will provide, but sometimes it’s just as important to itemize
what you will NOT deliver. This helps you avoid awkward “But weren’t you going to” questions or requests.
 Costs: This is an optional portion of your project SOW, depending on the type of organization you work in.
 Agreement: Scope documents create agreement by nature, but sometimes you need proof. So include a signature field in
your scope document and have your lead stakeholder or project funder sign the document.
 2.4 Identification and revising References
MDS allows the definition of business rules to enforce data quality and consistency. This ensures that the entered data
adheres to predefined standards and validation criteria
Master Data Services (MDS): Master data service implementations may vary; the services can be characterized within three
layers:
 Core services, which focus on data object life cycle actions, along with the capabilities necessary for supporting general
functions applied to master data
 Object services, which focus on actions related to the master data object type or classification (such as customer
or product)
 Business application services, which focus on the functionality necessary at the business level
 Reference Tables

Calendar Tables: Tables that display days, weeks, and months in a calendar format, often used for scheduling and planning.
Reference data is not purely descriptive.
Reference tables are used to store information that is commonly used to set up context and describe other business keys.
 Figure 2.1: Figure for a non-histories reference table for calendar (logical design)
1. Logic design templates
Programming logic model template is a template that is simply-formatted to use when developing a program's goals and
objectives.
 Table 2.6 sample logic design templates

input activities outcomes

what we invest what we do who we reach why this project short why this project short why this project long term
term result intermediate result result

Assumptio Assumptions External Fact

n
 2.6 Logic design validation
 Verification and Validation
Software verification provides objective evidence that the design outputs of a particular phase of the software
development life cycle meet all of the specified requirements for that phase.
Software verification looks for consistency, completeness, and correctness of the software and its supporting
documentation, as it is being developed, and provides support for a subsequent conclusion that software is validated.
Software validation is a part of the design validation for a finished device, but is not separately defined in the Quality
System regulation.
For purposes of this guidance, FDA considers software validation to be "confirmation by examination and provision of
objective evidence that software specifications conform to user needs and intended uses, and that the particular
requirements implemented through software can be consistently fulfilled.
Software verification and validation are difficult because a developer cannot test forever, and it is hard to know how
much evidence is enough.
In large measure, software validation is a matter of developing a "level of confidence" that the device meets all
requirements and user expectations for the software automated functions and features of the device.
 Gaining Feedback or Input
The great leadership guru Ken Blanchard likes to say that “Feedback is the breakfast of champions.” He is right; getting high-
quality feedback from customers can make a phenomenal difference to a company’s bottom line Yet so, few business owners
actually seek feedback on their performance.
 Good customer feedback can help to do a number of things, including:
 Improve products.
 Alter pricing structure.
 Retain customers for longer.
 Identify high- and low-achieving staff.
A . Ask new customers why they chose your service brand. This can be hard to do as many customers will feel uncomfortable
speaking with a company representative directly.
For this reason, it is important to establish a comfortable rapport so that customers feel they may speak openly and honestly.
B . Ask current and past customers what differentiates your service brand from others. Another approach is to ask a
customer what thought or image first comes to mind when they consider your company.
Then the first thought or image when considering a competitor’s brand. There is no right or wrong answers.
C . Who are your repeat customers? Look for areas of commonality among your repeat customers. This is an important clue to
how your brand is perceived in the marketplace.
Is your business obtaining referrals? If your brand is perceived accurately by customers, then word-of-mouth is a great source
of new business. What customers say about your company’s brand speaks louder than any promotional message.
D .Contact customers who chose a competitor. Assume a friendly tone and stress that your call is not sales-oriented. You
simply wish to follow up on why they didn’t choose your firm.
E. Is your brand an integral part of your core values? Both Starbucks and Union Square align their service branding strategy
with company values. Company core values are just that: they are the rock upon which your firm is built and, as such, unchanging.

Spending time understanding the perception of your service brand is a highly valuable exercise. It ensures that your firm is
reaching its intended audience and aligning customer expectations with service delivery.
 GROUP MEMEBERS

• TARIKUWA REGASSA
• SENA GEBISA
• BEAMLAK SOLOMON
• BRUKTAWIT MELKAM