Many of us have repetitive tasks to complete. Often we find that if we don't have any guidance, we may forget certain steps in a process. Sometimes even with simple steps involved we can get distracted and forget one or more of the required procedures.
It is easy for us to forget things and recovery is usually more complex than getting it right the first time. A simple tool that helps to prevent these mistakes is the checklist. A checklist is simply a standardized list of the required steps developed for a repetitive task. Checklists can help us stay more organized by assuring we don't skip any steps in a process. They are easy to use and effective.
2. 1. Whichtype of methodologyyourwilluse foryourprojectsequential oriterative.Provide enough
justification for the one you will use.
We are going to use Iterative Methodologyin our FYP. Although our requirementsare fixed
and not changing but main reason of using iterative method is because we cannot develop
whole systemorproductin single cycle, sowe use iterative modeltoimplementourproduct
initerationandsplitrequirementsformultiple iterationandatendof each iterationwe have
toevaluate the developmentprocessandensurethatthe currentiterationrequirements fulfil
the quality requirement and they are fully functional.
2. For your functional requirements answer the following:
2.1 List the inputs to your system along with their source, accuracy, range of values, and
frequency?
List of inputs:
o A high-resolution map image with extension like (jpg, jpeg, png).
o Specifications of property (id, name, address, size etc).
2.2 List the outputs from your system including their destination, accuracy, range of values,
frequency, and format?
List of Outputs:
o An SVG type image after image processing.
o Reports (daily, weekly etc).
o Alert generation.
2.3 Are all output formats specified for Web pages, reports, and so on?
No all outputs are not specified for webpages.
2.4 Are all the external hardware and software interfaces specified?
Yes, all the s/w & h/w interfaces are specified.
2.5 What data will be used in most common use cases?
3. For Requirements Completeness:
3.1 Where information isn’t available before development begins, are the areas of
incompleteness specified?
All requirements are available there not a single requirement which is not available.
3.2 Are the requirementscompleteinthe sensethatif the productsatisfieseveryrequirement,it
will be acceptable?
Yes,all the requirementsare completed,anditwellbe acceptableifthe productsatisfiesevery
requirement.
4. For your software architecture answer the following questions:
4.1 Is error processing corrective or merely detective? Elaborate your strategy of handling the
errors.
it’s merely detective, the programcan continue processing as if nothing had happened, or it can quit.
In either case, it should notify the user that it detected an error.
4.2 What are the conventions for handling error messages? You will use codes like HTPP Codes
200 means OK or directly messages. Mention Few.
We use direct messages for error handling we process exceptions which are generated by
systemand interprettheminsimple English, soa non-technical personcanunderstandwhat
goes wrong.
3. Is the overall organizationof the program clear, includinga goodarchitectural overview and
justification?
o Yes, overall organization of the program is clear, including a good architectural
overview and justification
? Are major building blocks well defined, including their areas of responsibility and their
interfaces to other building blocks?
o Yes, all major building blocks Are well defined, including their areas of responsibility
and their interfaces to other building blocks
? Are all the functions listed in the requirements coveredsensibly, by neither too many nor
too few building blocks?
o Yes
? Are the most critical classes described and justified?
o Yes,inour product mostcritical classincolour basedimage processingsegmentation
? Is the data design described and justified?
o No, we are working on it.
? Is the database organization and content specified?
o No, in coming weeks we will cover it.
? Are all key business rules identified and their impact on the system described?
o Yes, all key business rules are identified and their impact on the system described
? Is a strategy for the user interface design described?
o No, in coming weeks we will cover it.
? Is the userinterface modularizedsothatchangesinitwon’taffectthe restof the program?
o No, in coming weeks we will cover it.
? Is a strategy for handling I/O described and justified?
o No, in coming weeks we will cover it.
? Are resource-useestimatesandastrategyforresource managementdescribedandjustified
for scarce resourceslike threads,database connections,handles,networkbandwidth,andso
on?
o Yes
? Are the architecture’s security requirements described?
o No, in coming weeks we will cover it.