0% found this document useful (0 votes)
28 views

Sysana

The document discusses incremental project management models. It notes that incremental models allow for better coping with change, as errors can be identified and corrected sooner when new software is incorporated into the system. Incremental models involve building software in a step-by-step process similar to constructing a building. Requirements, specifications, and architecture must be completed before implementing software builds, with typical projects consisting of 10-25 builds. The document also summarizes problems with current blood bank systems, noting they are entirely manual, unreliable, inefficient in cost and time, lack security and permanent data storage, and have no user-friendly environment.

Uploaded by

Rushik Donga
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
28 views

Sysana

The document discusses incremental project management models. It notes that incremental models allow for better coping with change, as errors can be identified and corrected sooner when new software is incorporated into the system. Incremental models involve building software in a step-by-step process similar to constructing a building. Requirements, specifications, and architecture must be completed before implementing software builds, with typical projects consisting of 10-25 builds. The document also summarizes problems with current blood bank systems, noting they are entirely manual, unreliable, inefficient in cost and time, lack security and permanent data storage, and have no user-friendly environment.

Uploaded by

Rushik Donga
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

3.

PROJECT MANAGEMENT
3.1 Project planning and scheduling

3.1.1 Process model

Increamental model:
Problem with this model have been recognized for a long time.The emphasis in this
system is on document and writing. The building a program led to many new ideas: Planning,
specification as blue print component; assembly scaffolding: etc.But the idea that planning
preceded construction remained. In 1971, Harlan mills proposed that we should grow software
rather than build it. Ideally, the software grows like forever or a tree; occasionally, however, it
may spread like weeds. The fancy name for growing software is increamental development.

Coping with change:


There are many variations on this theme.One of the main advantages of this incremental
model is their ability to scope with change during the development of the system. For an
example,consider an error in the requirements.With this model,the error may not be noticed until
acceptance testing.When it is probably too late to correct it.(notice that the client probably
doesn’t see the software running the acceptance tests.)

In the increamental model, there is a good chance that a requirement error will be
recognized as soon as the corresponding software is incorporated into the system.It is then not a
bug deal to correct it .This model relies on careful review of document to avoid errors. Once a
phase has been completed, there is limited provision for stepping back. It is difficult to document
to verify documents and this is, again, a weakness of a model.

There is a wide array of development process tagged as increamental models.they all take
their origins in the above mentioned deficiency of the model,i.e. its inability to cope with
change.In the incremental models,software is build not written.Software is constructed step by in
the same way a building is constructed. The product is designed, implemented and tested as a
series of incremental builds,where a build consist of code pieces from various modules
interacting together to provide a specific functional capability and testable as a whole. The
requirements, specification and architectural design must be completed before implementation
for the various builds commences. A typical product will consist of 10-25 builts.
4. SYSTEM ANALYSIS
4.1 Study of current system
We know that previous blood bank contains total work that is to be performed
manually.If the work is manually there are lots of chances of mistakes.Many misunderstanding
takes place due to communication problem.As we developed this project after detail study of
many present blood bank system,we weren’t able to find a proper level of any management. This
is because of the manual management process still being used at many places.Computer-based
management of is very rare at present.What could be the reason behind it? The only possible
thing could be the difficulty to understand the work on any complex application.

4.2 Problem and weakness of current system


 System totally based on manual management scheme
 System is not reliable and accurate
 System takes much time to under go any task;as it would be without proper
acknowledgement.
 Difficult to establish connectivity between different departments.
 Chances of data duplication
 System would cost and time inefficient
 There won’t be any security or any permanent storage of data
 Difficult to access and retrieve any data
 This system does not provide any user friendly environment

You might also like